Coordinated vulnerability disclosure policy

Version 1.0 · 6 September 2026 · the policy referenced by security.txt

If you have found a security problem in this site or in something I publish, I want to hear about it. This page says what to send, what I will do, how quickly, and what I will not do to you for telling me.

Scope

In scope:

• This website, oosterloo.eu, and its subdomains.
• Software and firmware I publish under my own name, including the DCSwitch firmware described in the audit.
• The mail and DNS configuration of this domain — authentication, records, anything that would let someone impersonate it.

Out of scope, and why:

• Client systems and client firmware. Not mine to authorise testing against, and I cannot grant you safe harbour over someone else's property. If you have found something in a product I worked on, report it to that manufacturer under their own policy. If you cannot find one, write to me and I will pass the report on and tell you I have done so.
• Third-party services this domain depends on — the mail provider, the host, the registrar. Report those to them.
• Findings from automated scanners with no demonstrated impact — a missing header, a TLS configuration preference, a rating from an online grader. I will read them, but they are not vulnerabilities and I will say so.

What I commit to

These are one person's timelines, and they are set to be kept rather than to impress. A one-person practice cannot honestly promise a one-hour acknowledgement, and a policy that promises what it cannot deliver is worse than one that promises less. If what you have found is being actively exploited, say so in the subject line and I will drop whatever else I am doing.

I will also:

• Credit you by name or handle when the fix is published, unless you ask me not to.
• Tell you when it is fixed, and what the fix was.
• Publish the finding once it is fixed, in the same detail as I published my own failures in the audit. This site argues that disclosed failures are more useful than claimed successes; that has to apply to mine.
• Support a shorter timeline where the risk warrants it, or a longer one if a fix genuinely needs it — agreed with you, not imposed on you.

What I ask of you

• Give me enough to reproduce it. A request, a payload, a file and line, a commit — whatever makes it concrete. I would rather have a rough report with a reproduction than a polished one without.
• Stop once you have demonstrated the problem. Do not pivot further into the system, and do not run automated scans heavy enough to degrade service for anyone else.
• Do not access, modify, exfiltrate or retain data that is not yours. If you encounter personal data, stop and tell me what you found without copying it.
• No social engineering, phishing or physical attacks against me or anyone else. The scope is technical.
• Give me the agreed window before publishing. If I go quiet past the timelines above, you are entitled to publish; see below.

Safe harbour

Good faith means what it says: you were trying to find and report a problem, not to cause damage, extract data or extort a payment. A report accompanied by a demand for money is not a disclosure, and will be treated as what it is.

If I do not respond

You should not have to chase me, and you are not obliged to keep a finding secret indefinitely because I went quiet. If I miss the timelines above and you have had no answer, publish. Coordinated disclosure is a two-way arrangement, and a vendor that stops answering has ended it.

Before that, it is worth trying cra@oosterloo.eu in case something has gone wrong with mail delivery to the security address — which would itself be a finding I would want to know about.

You can also escalate to a national CSIRT. I am established in the Netherlands, so NCSC-NL is the relevant coordinator for anything I publish, and the Dutch coordinated vulnerability disclosure guidance is the framework I am working to. If you are reporting from France, CERT-FR (ANSSI) is an equally legitimate route and French law explicitly protects a researcher who reports in good faith to ANSSI rather than to the operator. Either way, going to a CSIRT first is a legitimate choice and I will not treat it as hostile.

What this is not

• There is no bug bounty and no payment. I am a one-person practice and I am not going to pretend otherwise. What I offer is a fast, honest response, public credit, and a published fix. If you need payment for your time, say so up front and we will both save it.
• This is not a penetration-testing authorisation for anything but the scope above. It does not make you an authorised tester of my clients.
• This page is not legal advice and does not alter anyone's obligations under applicable law.

Why this page exists

Annex I Part II of the Cyber Resilience Act requires manufacturers to have a coordinated vulnerability disclosure policy. Finding C1 of my own audit was that I did not have one — no published contact, no procedure, no way for anyone to tell me. The Article 14 clock starts when you become aware of a problem, and with no inbound channel, awareness arrives via a customer or a journalist.

It would be difficult to argue that manufacturers should fix that while leaving it broken here. A security.txt file publishes a contact point; it is not a policy. This is the policy.

Changes to this page are versioned. Version 1.0, 6 September 2026.