Security

Vulnerability disclosure policy

If you have found a security issue in Keylane, we want to hear about it, and we would rather hear about it from you than from an incident. This page sets out how to report one and what we commit to in return.

Machine-readable version: /.well-known/security.txt (RFC 9116)

Report to

Report a vulnerability

Or by email if you prefer: security@livotov.eu

Acknowledgement within 3 business days. Assessment within 10 business days.

Please do not open a public GitHub issue for a security vulnerability.

Scope

In scope

  • The Keylane Android and iOS applications
  • The public relay at router.keylane.app
  • The Keylane server and its admin console
  • The Kodium cryptographic core
  • The protocol itself — design flaws count, not only implementation bugs
  • This website, keylane.app

Out of scope

  • Findings that require a compromised or unlocked device — see the threat model
  • Denial of service, volumetric attacks, and rate-limit exhaustion
  • Social engineering of our staff or our users
  • Physical attacks against our premises or people
  • Missing hardening headers with no demonstrated impact
  • Automated scanner output submitted without analysis
  • Third-party self-hosted instances you do not operate

What to include

A report we can reproduce gets fixed faster than a report we have to investigate first.

  1. Description and impact

    What the issue is, and what an attacker gains from it.

  2. Reproduction steps

    Enough detail for us to observe the behaviour ourselves.

  3. Environment

    App version, platform and OS version, or the server endpoint concerned.

  4. Your attribution preference

    How you would like to be credited, or that you would prefer not to be.

What we commit to

We will acknowledge quickly

Within 3 business days, from a human rather than an autoresponder.

We will keep you informed

Progress updates until the issue is resolved or we explain why we disagree.

We will not threaten you

No legal action against researchers acting in good faith under this policy.

We will credit you

Publicly, in the changelog, unless you ask us not to.

We will disclose fixes

Security-relevant fixes are described in release notes rather than shipped silently.

We will be honest about severity

We will not downgrade a finding to avoid an uncomfortable disclosure.

Safe harbour

Good-faith research

If you make a good-faith effort to comply with this policy during your research, we will consider it authorized, will not pursue or support legal action against you, and will help make clear that your actions were conducted under this policy should a third party raise a concern.

Acting in good faith means: staying within the scope above, using only accounts and data you own, not accessing or exfiltrating other users’ data, not degrading the service for others, and giving us a reasonable opportunity to fix the issue before disclosing it publicly.

Coordinated disclosure

We ask for 90 days from acknowledgement before public disclosure, or until a fix ships, whichever is sooner. If we need longer we will say so and explain why rather than letting the clock run out in silence.

If we fail to respond within the timelines on this page, publishing is a reasonable response and we will not treat it as a breach of good faith. A disclosure policy that only binds the researcher is not a policy.

Rewards

Keylane is self-funded and does not currently run a paid bug bounty. We would rather say that plainly than advertise a programme we cannot fund properly.

What we do offer is public credit, a direct line to the people who wrote the code, and a genuinely fast fix. A funded bounty programme is on the roadmap for when revenue supports it.

Not a security issue?

General problems and questions go to support. Legal process goes through the legal request form or legal@livotov.eu — see the transparency report.

Report a vulnerability