Vulnerability Disclosure Policy
If you have found a security problem in this blog, we want to hear about it. This page sets out what we ask of you, and what we commit to in return.
Last updated:
01What this policy covers
This policy covers blog.sekurity.de and nothing else: the application that renders it, the content we publish on it, and the configuration we control.
It is deliberately narrow. This is a static site running on infrastructure we rent, so a good deal of what your traffic touches is not ours to authorise testing against. The next two sections say exactly where that line falls, because a scope you have to guess at is not a scope.
- Injection, cross-site scripting, or content spoofing in pages served from blog.sekurity.de
- Broken access control, or information disclosure in the site or its build output — secrets in the deployed bundle, for instance
- Misconfigured HTTP headers, redirects, or routing rules that we define
- Defects in our
security.txt, our published PGP key, or this policy itself
02What is out of scope
Reports in these categories are closed without assessment. That is not a judgement about whether the underlying issue is real — several of these are real, and belong to someone else.
- Denial of service, volumetric testing, or anything that degrades availability. It would land on our hosting provider rather than on us, and we cannot authorise it.
- Automated scanner output with no demonstrated, exploitable impact on this site.
- Missing hardening headers, weak TLS ciphers, and similar best-practice findings with no working exploit path. Send them anyway if you like — we will read them — but they are not vulnerability reports.
- Self-XSS, clickjacking on pages with no state-changing action, mail records on domains that send no mail, and version disclosure without a working proof of concept.
- Social engineering of any person, physical attacks, and anything that targets a human being rather than the system.
- Findings in the third-party services this site loads — see below.
- Other SEKurity properties, including www.sekurity.de. The contact address is the same, but the scope and safe harbour on this page do not extend to them.
03Infrastructure we do not operate
We write the content and the code; we rent everything underneath. We cannot grant permission to test systems we do not operate, and this policy does not pretend to.
If your finding is in one of the services below rather than in our application, report it to its owner. They run real disclosure programmes and can actually fix it. We can do neither.
Vercel
Hosting, the edge network, TLS termination, the build pipeline, and the analytics, speed-insights and toolbar scripts this site loads.
04How to test without causing a problem
Testing this blog necessarily routes traffic through our hosting provider. That is unavoidable, and we do not object to ordinary, low-volume manual testing of our application.
You remain responsible for complying with those providers’ own terms as well as this policy. Nothing here overrides them, and we are not in a position to waive them on your behalf.
Keep request rates to something a human could plausibly generate, stop as soon as you have proof, and test against your own data rather than anyone else’s.
05How to report
Email security@sekurity.de. If the finding is sensitive, encrypt it with our PGP key — the same key that signs our security.txt.
A report we can reproduce gets fixed faster than a thorough one we cannot, so lead with the reproduction.
- The URL or component affected, and enough detail to reproduce it
- What an attacker gains — the impact, not only the mechanism
- A proof of concept, ideally the smallest one that demonstrates the issue
- Whether you intend to publish, and roughly when
06What we commit to
We are a small team, so these are deliberately unambitious numbers that we can actually meet. In practice most reports get an answer the same week.
- We acknowledge your report within 5 business days
- We give you an initial assessment — in scope or not, and our view of severity — within 15 business days
- We update you at least every 30 days while the issue is open
- We tell you when it is fixed
07Safe harbour
If you follow this policy, SEKurity GmbH will not pursue civil claims against you, and will not seek or support criminal prosecution, over your research. We consider that testing authorised.
That word matters here. German law criminalises unauthorised access under §§ 202a–202c StGB, and authorisation is precisely the difference between research and an offence. If a third party brings an action over research you carried out on our site within this policy, we will state — publicly and in writing — that it was authorised.
The limits, stated plainly, because a safe harbour with hidden edges is worse than none at all:
- It binds SEKurity GmbH alone. We cannot grant immunity on behalf of our hosting provider, or anyone else whose systems your traffic crosses.
- It applies to testing within the scope above. Pivot to other hosts, reach another person’s data, or degrade availability, and it does not apply.
- It does not cover extortion. A report conditioned on payment is not research, and we will treat it accordingly.
- It assumes good faith: stop at proof, take the minimum data needed to demonstrate the issue, do not retain or share it, and tell us what you accessed.
08Coordinated disclosure
We would like to fix an in-scope report before it is published, and we ask you to hold publication until the fix ships or 90 days from your report, whichever comes first.
Ninety days is a ceiling, not a target. If we fix it in a week, publish in a week. If we need longer we will ask, explain why, and accept that the decision is ultimately yours.
We will not ask you to sign a non-disclosure agreement as a condition of reporting, and we will not use a disclosure timeline to bury a finding.
09Recognition
We do not run a bug bounty and we do not pay for reports. Saying so plainly is fairer than letting you discover it after the work.
What we can offer is credit: we will name you, with a link of your choosing, in the fix and anywhere we write the issue up — or keep you anonymous if you would rather.
Reporting channel
- security@sekurity.de
- PGP key
- https://blog.sekurity.de/pgp-key.asc
8AE8 B278 FF65 1C43 2196 0CEB F29B 8AB7 CC6C FCEC