Security

Responsible Disclosure

How to report a security issue in our products, what to expect from us, and the scope we cover.

Last updated: 28 May 2026  ·  security.txt: /.well-known/security.txt

If you believe you have found a security vulnerability in any product or service operated by Myur Labs UG (haftungsbeschränkt) — including osdp.dev, the Osprio product family, or our firmware and software — please report it to [email protected] before disclosing it publicly. We are committed to working with researchers in good faith.

1. How to report

Email reports to [email protected]. For sensitive findings, please encrypt your report using our PGP key, available at github.com/sidcha.gpg. The fingerprint is also published in our machine-readable disclosure file at /.well-known/security.txt.

Please do not open public issues on GitHub, file public bug trackers, or post on social media until we have had a reasonable opportunity to investigate and remediate.

2. What to include

To help us triage quickly, your report should include:

  • A clear description of the issue and its potential impact.
  • The product, version, firmware revision, or URL affected.
  • Step-by-step reproduction instructions, ideally with a minimal proof of concept.
  • Any logs, network captures, or screenshots that demonstrate the problem.
  • Your name or handle (if you would like to be credited) and contact details for follow-up questions.

3. Scope

The following are in scope for coordinated disclosure:

  • Web properties under *.osdp.dev (this marketing site, the documentation site, the shop, the API).
  • Firmware shipped for OsprioPro and OsprioMini hardware.
  • OsprioView desktop application binaries distributed by us.
  • Open-source code in repositories we maintain, including issues introduced by our own modifications to upstream dependencies (e.g. LibOSDP).
  • Cryptographic implementations in our OSDP secure-channel stack.

The following are out of scope and will be closed without action:

  • Vulnerabilities in third-party services we use but do not operate (e.g. our DNS provider, font CDN, email host) — please report those to the relevant vendor directly.
  • Self-XSS, clickjacking on pages without sensitive actions, or attacks requiring full physical access to an unlocked end-user device.
  • Missing security headers (e.g. CSP, HSTS) without a demonstrated exploitable impact.
  • Best-practice suggestions (rate-limiting hardening, header tuning) without a concrete attack scenario.
  • Reports generated solely by automated scanners with no manual validation.
  • Social engineering of our staff, customers, or contractors.
  • Denial-of-service attacks, load testing, or anything that would degrade service for other users.

4. Our commitment

When you report in good faith and within the scope above, we commit to:

  • Acknowledge receipt within 3 business days.
  • Triage and provide an initial assessment within 10 business days.
  • Communicate regularly about progress until the issue is resolved or formally closed.
  • Credit you in a public acknowledgements section if you wish, once the issue is fixed and disclosure has been coordinated.
  • Not pursue legal action against researchers who follow this policy in good faith — see Safe Harbour below.

We aim to remediate critical issues within 30 days, high-severity issues within 60 days, and medium or lower within 90 days. Some issues — particularly in shipped firmware — may take longer due to deployment logistics, and we will tell you when that is the case.

5. Safe harbour

We will not pursue civil or criminal action — and will request that public authorities not pursue you either — for security research conducted in good faith that:

  • Stays within the scope defined above.
  • Avoids privacy violations, destruction of data, and interruption or degradation of our services.
  • Uses only your own accounts or accounts you have permission to test.
  • Gives us a reasonable opportunity to remediate before public disclosure.

6. Encrypted communication

For sensitive reports, please encrypt to the PGP key at https://github.com/sidcha.gpg. If you cannot use PGP, send an unencrypted summary asking us to share an alternative secure channel (for example, an end-to-end encrypted file drop).

7. Acknowledgements

We thank the researchers who have helped us improve the security of our products. A public hall of fame will be published here as the program matures.

8. Bug bounty

We do not currently operate a paid bug-bounty programme. We may offer discretionary token rewards (swag, product credits, or, for severe issues, monetary thanks) on a case-by-case basis. This is a goodwill gesture, not a contractual entitlement.

9. Updates to this policy

We may update this policy at any time. Material changes will be reflected in the "Last updated" date at the top of this page and in the Expires field of our security.txt.