SteadySec Your retained security partner

At full delivery capacity until the end of 2026.

Security and vulnerability disclosure

We advise clients to publish a reporting contact and run a coordinated disclosure process . This is ours. If you have found a weakness in steadysec.eu, this page tells you where to send it, what we will do with it, and what we will not do to you.

Last updated: 15 August 2026

Where to send it

How to report

Email hello@steadysec.eu with "Security report" in the subject line. The same address is published as the Contact field in our security.txt. There is no web form for this: a form would be one more input to trust, and email keeps the exchange in a channel you control.

A useful report contains

  • The affected URL or asset, and the date and time you tested.
  • Steps to reproduce, precise enough that we can follow them without guessing.
  • What an attacker gains: the impact, not just the classification.
  • Any proof of concept, screenshot, or request and response capture.
  • How you would like to be credited, or that you would rather not be.

Write in English or Czech. If a finding is sensitive enough that you would rather not put it in plain email, say so in a first message and we will agree an encrypted channel before you send the detail.

What this covers

Scope

In scope

  • steadysec.eu and any subdomain we operate
  • The static site itself: content injection, client-side scripting flaws, and the interactive Discovery Calculator
  • HTTP security headers, TLS configuration, and DNS records under our control
  • Files published under /downloads
  • Email authentication for steadysec.eu (SPF, DKIM, DMARC)

Out of scope

  • Systems belonging to our clients. Nothing on this page authorises testing against them.
  • Third-party services we consume rather than operate: Proton, Cloudflare, counter.dev, and the Ransomware.live feed. Report those to their own programmes.
  • Volumetric denial of service, load testing, and anything that degrades the site for other visitors.
  • Social engineering, phishing, or physical intrusion aimed at us, our clients, or our suppliers.
  • Scanner output with no demonstrated impact, including missing headers that are already set, version-disclosure banners, and self-XSS.
  • Reports that a cookie flag or session control is absent. This site sets no cookies and has no accounts or sessions.

Out of scope does not mean unwelcome. If you have found something adjacent that we should know about, send it anyway and we will route it to whoever owns it.

How to test

Rules of engagement

Look, do not take

Access only the data needed to prove the issue. If you encounter personal data, stop, do not save or copy it, and say so in your report.

Do not disrupt

No denial of service, no destructive testing, no automated scanning heavy enough to affect availability for other visitors.

Give us time

Report promptly and keep the finding between us until a fix ships or 90 days pass, whichever comes first. If we need longer, we will ask rather than go quiet.

Make it reproducible

Include the URL, the steps, the request and response where relevant, and what an attacker would gain. A short proof of concept is worth more than a scanner export.

What happens next

What you can expect from us

Working days are Monday to Friday, Central European Time. These are commitments, not aspirations. If we miss one, chase us and we will explain.

Acknowledgement

3 working days

A human reply confirming the report arrived and who is handling it. Not an autoresponder.

Triage and validation

10 working days

We reproduce the issue, agree a severity with you, and tell you whether we accept it, consider it out of scope, or need more detail.

Remediation

Communicated after triage

A fix date proportionate to severity. If it will take longer than expected, you hear why rather than nothing.

Closure and credit

On deployment of the fix

We confirm the fix, invite you to verify it, and credit you by the name you choose unless you prefer to stay anonymous.

Your protection

Safe harbour

If you research in good faith and follow the scope and rules above, we will treat your work as authorised. Specifically, we will not bring or support a legal claim against you in relation to that research, and if a third party does, we will make clear that you were acting with our permission.

This protection is ours to give for our own systems only. It does not extend to client environments, to third-party services listed as out of scope, or to activity outside the rules above. Nothing here overrides applicable law, and we cannot waive the rights of anyone else.

If you are unsure whether something is permitted, ask first at hello@steadysec.eu. Asking is always the safer move, and we would rather answer a question than receive an apology.

Being straight about it

This is not a bug bounty

We do not pay for reports. A small firm running a static marketing site cannot fund a bounty programme honestly, and a programme that quietly never pays is worse than none at all.

What we do offer is a fast human reply, a real fix, public credit in the name you choose, and a written reference for your disclosure record if that is useful to you.

Credit where due

Acknowledgements

No reports have been received and resolved yet. Researchers who report a valid issue are listed here once the fix is live, unless they ask not to be.

Attack surface

How this site is built

Useful context before you start, and a fair statement of what we practise ourselves. The smallest attack surface is the one you never deploy.

  • Static by design. Pre-rendered HTML on a CDN. No application server, no database, no user accounts, no sessions, no admin panel.
  • No cookies. The only browser-local value is your light or dark theme preference, which never leaves your device.
  • The Discovery Calculator runs entirely in your browser. Answers are never transmitted anywhere unless you choose to email the summary yourself.
  • One third-party subresource in total: a cookieless page counter. Fonts are self-hosted, there is no icon font, no tag manager, and no advertising or session-recording script.
  • Content Security Policy, HSTS with preload, frame-ancestors none, and nosniff are set on every response.
  • Everything published here is generated from a version-controlled source, so a change is always attributable to a commit.

How personal data is handled is a separate question, answered in the privacy notice.

Anything else

Not a vulnerability report?

If you need a disclosure process like this one for your own product, it is part of what CRA readiness covers. See CRA readiness, or start with the questions below.