Skip to content
ReadinessNavigator
EnglishDeutsch

Security

Reporting a security vulnerability

If you find a vulnerability in readinessnavigator.com, please tell us before anyone else. This page explains how to report it and what you can expect from us.

How to report

Send your report by email to security@readinessnavigator.com.

Please include

  • A description of the vulnerability and where it is, such as the URL or the feature.
  • Steps to reproduce it, or a proof of concept.
  • The impact you believe it has.

Reports in English or German are welcome.

If you would rather not send full details by unencrypted email, send a short first message and we will agree an encrypted channel.

What happens next

  1. We confirm receipt within five working days.
  2. We investigate, tell you whether we can reproduce the issue, and keep you updated until it is resolved.
  3. Once it is fixed, we credit you by name or handle if you wish. Tell us how you would like to be named.
  4. Please keep the details confidential until the issue is fixed or we have agreed a disclosure date with you.
  5. There is no bug bounty: we do not pay for reports.

Scope

In scope

  • readinessnavigator.com, including the assessments, the SBOM check, the CRA reporting deadline planner and the /api/kev endpoint.
  • mta-sts.readinessnavigator.com, the host that serves our mail security policy.
  • The domains that redirect to this site: www.readinessnavigator.com, cranavigator.com, www.cranavigator.com and cranavigator.de.

Out of scope

  • Denial-of-service, load testing, or anything else that degrades the site for other visitors.
  • Social engineering, phishing and physical attacks.
  • Services we use or link to but do not operate, such as our hosting platform, our email provider, Cal.com, OSV.dev and CISA. Please report those to the provider directly.
  • Reports based only on automated scanner output, without a demonstrated impact. This includes the wildcard Access-Control-Allow-Origin header on public pages and the 'unsafe-inline' source in our Content Security Policy, which are known and assessed. A working injection or data-exposure path is in scope.

Intended behaviour

  • The assessments and the SBOM check run in your browser. Answers and files are not sent to us.
  • When a visitor starts the SBOM vulnerability check, their browser sends package identifiers to OSV.dev. This is disclosed on the page and in the privacy notice.
  • Assessment progress and saved results live in your own browser storage. Changing your own stored data is not a vulnerability.
  • Public pages and /api/kev return public information to anyone who asks.

Good faith

We ask that you:

  • stay within the scope above;
  • access, change or keep only the data you need to demonstrate the issue, and delete it afterwards;
  • avoid harming visitors, their data or the availability of the site;
  • do not use the issue to reach other systems;
  • give us reasonable time to fix the issue before you disclose it publicly.

If you do, we treat your research as made in good faith. We will not take legal action against you or file a criminal complaint about it.

This commitment covers only our own rights as the operator of this site. It cannot authorise access to systems run by others, such as our hosting or email providers, and it cannot rule out action by authorities or third parties. If you are unsure whether something is in scope, ask us first.

Machine-readable contact details

The same contact details are published in a security.txt file following RFC 9116, so scanners and researchers can find them automatically.

/.well-known/security.txt

Last updated: 3 October 2026