Coordinated Vulnerability Disclosure

Security Contact

Found a security issue in DevGuard? We want to hear about it before anyone else does. Report it privately, we triage it, ship a patch — and then publish the advisory together with you.

How to report

Two ways to reach us privately

Both channels notify the maintainers directly and keep your report confidential until a fix is available. Pick whichever fits you — GitHub is the fastest path for anything in our repositories.

Recommended

GitHub Private Vulnerability Reporting

Open the “Report a vulnerability” form on the DevGuard repository. Only the maintainers are notified, and the whole exchange — questions, patch, draft advisory — happens in that private thread. In the best case, once the vulnerability is fixed, the report is published as a public advisory.

Email the L3montree development team

Prefer email, or found something that is not tied to a repository — an anomaly on a hosted instance, for example? Write to developer@l3montree.com. This starts a Coordinated Vulnerability Disclosure with the development team.

developer@l3montree.com
PGP public key

Fingerprint 8360 AF73 C2B5 6CFA FDC8 5337 A715 0822 2B61 68D5

Scope

One address for the whole ecosystem

DevGuard is more than one repository: the platform and API, the web frontend, the CLI and scanner, the Helm chart, our CI components, and the smaller ecosystem projects. Report a finding in any of them through the DevGuard advisory form or by email — we route it to the right repository and maintainer.

That also covers this website and our hosted instances. If you are unsure whether something is in scope, report it anyway and let us judge.

Process

What happens after you report

We follow Coordinated Vulnerability Disclosure: the vulnerability stays private until there is a fix, and it is disclosed together with that fix.

  1. 01

    Private notification

    Your report reaches the maintainers first. Nothing about it becomes public at this stage.

  2. 02

    Triage

    We reproduce the issue, assess its impact, and come back to you with our assessment and any follow-up questions.

  3. 03

    Patch

    Where possible, the team develops and releases a security patch within a week of confirming the vulnerability.

  4. 04

    Disclosure

    The vulnerability is made public in the course of the patch release. If you wish, you are named as the reporter.

Guidance

What makes a report easy to act on

Please do include

  • The affected component and its version, image tag, or commit.
  • Concrete reproduction steps, a proof of concept, or a request/response pair.
  • What you expected to happen versus what actually happened.
  • Your own impact assessment — what an attacker could reach, and under which preconditions.
  • Anything specific about your deployment: configuration, integrations, self-hosted or SaaS.
  • Whether you plan to publish, and on what timeline, so we can coordinate.

Please avoid

  • Public issues, pull requests, or discussions for something that is not yet fixed.
  • Testing against instances you do not own — run DevGuard locally or self-host it instead.
  • Automated scanning that degrades a service, and any access to other people’s data.
  • Waiting for a perfect write-up: a short report now beats a polished one in three weeks.

Published security advisories

Every disclosed vulnerability, its fix, and the affected versions are documented in the DevGuard repository — including the reporters who chose to be credited.