Responsible reporting
Disclosure Policy
Our disclosure policy describes how security researchers can report vulnerabilities responsibly, and what they can expect from us throughout the process.
Last updated: August 2026
This is a convenience translation; the Danish version is legally binding.
What is responsible disclosure?
Responsible disclosure is a practice where security researchers report vulnerabilities directly to the affected organisation before they are made public. This gives the organisation time to fix the problem and protect its users.
At Defend.gl, we believe that transparency and collaboration are key to better cybersecurity. Our disclosure policy ensures a structured and respectful process for both parties.
When you report a vulnerability through Defend.gl, we commit to:
- Confirming receipt within 48 hours
- Keeping you updated on the status of your report
- Crediting you for your finding (if desired)
- Paying any bounties promptly
Why disclosure?
Publishing vulnerabilities without giving the organisation time to respond can put thousands of users at risk. Responsible disclosure protects everyone: users gain security, organisations gain time to fix issues, and researchers gain recognition.
How to report: step by step
- Verify the vulnerability. Make sure you can reproduce the vulnerability and document the steps. Take screenshots or record video if possible.
- Write a report. Describe the vulnerability clearly, with a title, description, reproduction steps, impact, and any proof of concept.
- Submit via the platform. Use Defend.gl's reporting form to submit your report securely. Avoid sending it through insecure channels.
- Wait for a response. We confirm receipt within 48 hours and keep you updated throughout the process, through to fix and payment.
What your report should include
A good vulnerability report makes it easier for us to understand and verify the issue. The more detailed your report is, the faster we can respond.
- Descriptive title: A clear title summarising the vulnerability, e.g. "SQL injection in the login form on example.gl".
- Detailed description: Explain what the vulnerability is, what type of vulnerability it is (XSS, IDOR, SQLi, etc.), and what causes it.
- Reproduction steps: Step-by-step instructions for reproducing the vulnerability. Include URLs, parameters, and any payloads.
- Proof of Concept: Screenshots, videos, or code samples that demonstrate the vulnerability. Keep the PoC minimal and avoid exfiltrating data.
- Impact assessment: Describe the potential impact: what could an attacker achieve? What data is at risk? How many users are affected?
- Suggested fix (optional): If you have suggestions for how the vulnerability could be fixed, this is always appreciated, but not required.
CVSS score
If you can, include a CVSS score to help assess the severity of the vulnerability. Use FIRST's CVSS calculator to calculate the score.
What you can expect from us
We commit to the following response times for all submitted reports:
- 48 hours: Confirmation of receipt with a report ID and an initial severity assessment.
- 7 days: Detailed assessment of the report with a decision on validity and a bounty estimate.
- 90 days: Standard disclosure timeline. The vulnerability is fixed and coordinated publication is agreed.
- 14 days: Payment of the bounty after verification and approval of the report.
90-day coordinated disclosure
Defend.gl follows a 90-day coordinated disclosure policy. This gives organisations sufficient time to develop, test, and implement a fix.
Standard timeline:
After 90 days from the initial report, the security researcher may publish details of the vulnerability, unless otherwise agreed.
Extension:
In complex cases, the timeline may be extended by mutual agreement. We communicate openly about status and the expected fix date.
Early disclosure:
If the vulnerability is being actively exploited, or if the organisation refuses to respond, the timeline may be shortened at our discretion.
Credit:
We always credit the researcher in our security advisories, unless the researcher wishes to remain anonymous.
Timeline overview
- Day 0: Report received
- Day 2: Confirmation sent
- Day 7: Assessment complete
- Day 30: Status update
- Day 60: Fix developed
- Day 90: Coordinated disclosure
Exceptions
Critical vulnerabilities that are being actively exploited may require faster action. In these cases, we work with the researcher on an accelerated timeline.
What we do not accept
The following types of reports will not normally be accepted or rewarded:
- Scanner output: Raw output from automated scanners without manual verification or context.
- Theoretical vulnerabilities: Vulnerabilities with no practical impact, or that cannot be demonstrated.
- Self-XSS: XSS that only affects the user carrying out the attack against themselves.
- Missing headers: Missing security headers without demonstrated exploitation or impact.
- Known vulnerabilities: Vulnerabilities that have already been reported, or that we are already working to fix.
- Social engineering: Phishing, vishing, or manipulation of employees is not permitted.
Have questions?
If you are unsure whether a vulnerability is in scope, or have questions about the disclosure process, feel free to contact us.
Use our contact form to send us a message. You can include your PGP key if you would like an encrypted reply. We respond to enquiries within 48 hours on business days.
Related policies
Found a vulnerability?
Use our secure reporting platform to submit your vulnerability report. We will review it as soon as possible.