Security

Report a vulnerability

OpenPDR runs inside other people's facilities and holds their operational data. If you have found a way to break that, we want to hear about it — early and rough beats late and polished.

Reporting

Email security@openpdr.dev. Report over ordinary authenticated TLS email; there is no key to fetch first, deliberately — see Encryption and PGP below.

Please include, as far as you can:

  • What you found and where — the product component, the endpoint, and the deployment shape: virtual appliance, Helm chart, or the managed / demo tier.
  • How to reproduce it — steps, a proof-of-concept, or a request/response capture.
  • The impact you believe it has, and any prerequisites: credentials, role, network position.
  • The version, image tag or commit, if you have it.
Please do not send us this

Do not include real third-party personal data, or another tenant's data, in a report. If a proof-of-concept would require exposing such data, describe the mechanism instead and we will reproduce it against test-org data on our side. A report loses nothing by leaving that out.

Scope

In scope
  • The openPDR product and the artifacts it ships
  • The virtual appliance
  • The Helm chart
  • The management / console plane
  • The telemetry bus
  • The managed tier and the demo deployment at demo.openpdr.dev
Out of scope
  • Findings against a customer's own deployment infrastructure — their host OS, cluster or network — rather than against openPDR itself
  • Volumetric denial of service
  • Social engineering of our staff or of customer staff
  • Reports whose only content is automated-scanner output with no demonstrated impact — the hardened image trips some scanner heuristics on purpose

The highest-severity class this product can face is a cross-tenant read — one organisation seeing another organisation's data — because tenant isolation is openPDR's first security promise. A credible report of that class is treated as our top severity on receipt, with no triage debate.

What happens next

We will acknowledge your report, and we will keep you updated as we investigate.

We publish no target response times on this page. OpenPDR is operated by a very small team, and a clock we might not keep would be worth less to you than a straight account of where your report actually is.

We practise coordinated disclosure: we ask that you give us a reasonable window to remediate before disclosing publicly, and we will keep you posted on progress and credit you if you would like to be credited. There is no paid bug-bounty programme at this stage — please do not let that stop you sending the report.

Encryption and PGP

No PGP/OpenPGP key is published, on purpose: advertising a key we do not hold and rotate would be worse than publishing none. Report over ordinary authenticated TLS email. If encrypted intake is later required, an Encryption field will be added to our security.txt at the same time a key is actually generated and custodied — not before.

Machine-readable metadata

This page is the Policy target of our RFC 9116 file, which is served — byte-identical — from both of our hosts: openpdr.dev/.well-known/security.txt and the same path on demo.openpdr.dev. Both copies list both URLs as Canonical, so either one is trustworthy whichever host you fetched it from.