Responsible Disclosure Policy

If you have found a security problem in one of our systems, we would rather hear it from you than from an attacker.

Last updated 17 September 2026 · Applies to devnician.net

Report a vulnerability

No form, no account, no waiting room. A short, rough report sent today is worth more to us than a polished one sent next month.

01Our commitment

Devnician designs and maintains software and connected systems. We take the security of those systems, and of the people who rely on them, seriously. Even so, no system is perfect: vulnerabilities can and do slip through.

This policy explains how to tell us about one, what we ask of you while you investigate, and what you can expect from us in return. We welcome reports from anyone — security researchers, customers, suppliers, or someone who simply noticed something odd.

02How to report

Send your report by email to security@devnician.net. Please include as much of the following as you can:

A description of the vulnerability and why you believe it is a security problem.
The affected system: URL, IP address, hostname, or product and version.
Clear steps to reproduce it. Proof-of-concept code, scripts, requests or screenshots are very welcome.
Your assessment of the impact — what could an attacker actually do?
Whether you intend to publish anything about the finding, and on what timeline.

Reports in English or Dutch are both fine. If you are unsure whether what you found qualifies, send it anyway.

03What we ask of you

Security research is welcome, but it has to stay proportionate. While investigating, we ask that you:

Report promptly once you have enough to demonstrate the problem.
Do no more than necessary. Proving you can read one record is enough; reading ten thousand is not.
Leave data alone. Do not delete, alter, or make unavailable any data or system.
Stop if you hit personal data. Stop at once, do not save or copy it, and say so in your report.
Keep it to yourself until we have agreed a disclosure moment with you.
Stay inside our perimeter. Do not pivot into systems belonging to our customers, suppliers, or other third parties.
Clean up. Remove any test accounts, files or shells you created, or tell us where they are so we can.

Please do not

Run denial-of-service or stress-testing attacks of any kind.
Deploy malware, ransomware, backdoors, or persistence of any sort.
Use phishing or any other social engineering against our staff, customers, or suppliers.
Attempt physical intrusion into our premises or those of our customers.
Brute-force credentials, or use credentials found in third-party breaches.
Run high-volume automated scanners that degrade service for others.

04What you can expect from us

5 business days	Acknowledgement that your email reached us.
10 business days	A substantive first assessment: whether we can reproduce the issue, and how we rate its severity.
Every 30 days	Progress updates, until the matter is closed.
Within 90 days	Remediation of confirmed vulnerabilities. If a fix will take longer, we will tell you why and agree a realistic timeline with you.

Coordinated disclosure. We are happy for you to publish once the issue is fixed, and we will agree the timing with you rather than impose it. We will not ask you to stay silent indefinitely.

A straight answer. If we decide not to fix something, we will tell you that and explain our reasoning, rather than let the report go quiet.

We do not operate a paid bug bounty programme, and we do not offer monetary rewards.

05Safe harbour

If you act in good faith and follow this policy, we will treat your research as authorised. We will not initiate legal action against you, and we will not report you to the authorities, in connection with research conducted within these rules.

If a third party brings legal action against you for research carried out in compliance with this policy, we will make it known that your actions were authorised under it.

Two honest limits on that promise:

We can only speak for ourselves. This policy cannot waive the rights of our customers, suppliers, or other third parties — which is why we ask you to stay inside our own perimeter.
Good faith is the condition. If a report turns out to be a pretext for extortion, data theft, or damage, this safe harbour does not apply.

06The Belgian legal framework

Since 15 February 2023, Belgium has had a statutory framework for coordinated vulnerability disclosure, which offers legal protection to people who investigate vulnerabilities in systems located in Belgium.

That protection carries its own conditions, set by law rather than by us. They include acting without fraudulent intent, keeping your actions necessary and proportionate, reporting the vulnerability to the organisation concerned as soon as possible, and also notifying the Centre for Cybersecurity Belgium (CCB). The framework likewise prohibits publishing details of a vulnerability without the CCB's agreement.

This policy sets out our own commitments to you. It does not replace those statutory conditions, and following it does not by itself make you compliant with them. If you intend to rely on the Belgian framework, please read the CCB's guidance at ccb.belgium.be/regulation/cvdp and follow it alongside this policy.

07Scope

In scope

Systems owned and operated by Devnician, including devnician.net and its subdomains.
Software and firmware published by Devnician.

Out of scope

Anything not operated by us, including third-party platforms and hosting providers we happen to use. If you find a vulnerability in one of those, please report it to the party that operates it.

08Findings we are unlikely to act on

The following are usually produced by automated tooling and, on their own, do not demonstrate a security problem. We will still read them, but we are unlikely to treat them as vulnerabilities unless you can show real impact:

Missing or misconfigured security headers with no demonstrated exploit.
SPF, DKIM, or DMARC configuration observations.
Missing rate limiting on endpoints that do not perform sensitive actions.
Self-XSS, or issues that require the victim to attack themselves.
Clickjacking on pages with no sensitive actions.
CSRF on forms with no meaningful effect.
Version-banner findings, or outdated software without a working exploit.
Certificate, TLS, or cipher-suite configuration preferences.
Raw output from automated scanners that you have not validated by hand.
Denial of service, resource exhaustion, and social engineering.

09Changes to this policy

We may update this policy. The date at the top reflects the most recent change. The version in force when you submitted your report is the one we will apply to it.