Skip to main content
The Marmot mascot in a security officer uniform holding a magnifying glass

Find a hole in Marmot? Tell us first.

Marmot holds the map of everything your company has: every table, topic, service and pipeline, and who owns it. That is exactly the kind of thing worth protecting well, so we run a disclosure program and a Vulnerability Research Program. This page is the whole program: how to report, what is in scope, and the rules.

Reporting a vulnerability

Send your report to security@marmotdata.io. Put the details in the body of the email as plain text, not in a PDF; attachments are for screenshots and proof-of-concept files. For issues in the open source code you can also use GitHub's private vulnerability reporting, which opens a draft advisory that only we can see.

If possible, include:

  • Steps to reproduce
  • The affected version, commit or URL
  • An impact summary: what an attacker gains

We are a small team, so your report is read by an engineer, not a triage vendor. We aim to acknowledge within two business days and to tell you within a week whether we can reproduce it. Please do not report security issues through Discord, GitHub issues or the support inbox; those are public or read by more people than need to see a vulnerability.

Scope

In scope:

  • The open source project: the marmot binary, the official plugins, the MCP server, the Helm chart and the container images we publish.
  • Marmot Cloud: cloud.marmotdata.io, api.marmotdata.io, and instances on marmotdata.cloud that you own.
  • How we ship: the integrity of releases and plugin distribution. If you can make someone install something we did not publish, we want to know about it more than almost anything else on this page.

Out of scope:

  • This website, marmotdata.io, and the docs. It is a static site with no accounts and nothing sensitive behind it.
  • demo.marmotdata.io. It is shared, intentionally open and resets itself.
  • Cloud instances that are not yours. Never test against another tenant, under any circumstances.
  • Third-party services we use. Report those to the third party.

What qualifies

Anything that breaks the security model of the catalog or the platform it runs on. The clearest examples:

  • Tenant isolation breaks on Marmot Cloud: reading or writing another tenant's metadata, configuration or credentials. This is the top of our severity scale.
  • Authentication or authorization bypass
  • Privilege escalation, in the product or in Cloud
  • Remote code execution
  • Injection of any kind that crosses a trust boundary, including SQL injection
  • Server-side request forgery, including through plugin configuration
  • Exposure of stored secrets: connection credentials, API keys, session tokens
  • Supply chain issues in how we build and distribute releases and plugins

What does not qualify

  • Automated scanner output without a working proof of concept
  • Self-XSS, or XSS that only affects the person triggering it
  • Clickjacking without a demonstrated harmful action
  • Missing security headers or cookie flags on pages with nothing sensitive on them
  • Username or email enumeration, and password policy opinions
  • Denial of service and rate-limit testing. Do not do this at all; it is against the rules below, not just non-qualifying.
  • Vulnerable dependency reports without a reachable path through our code
  • Anything that requires an already-compromised machine or stolen credentials
  • A self-hosted install with the safe defaults turned off. If you disable authentication on your own instance, that is a decision, not a finding.

Rules of engagement

  • Test only what you own: your own accounts, your own instances, your own self-hosted deployments.
  • If you find yourself looking at another tenant's data, stop. Record the minimum needed to prove the issue, report it, and do not keep copies.
  • No denial of service, no volumetric scanning, no spam, and no automated tooling that generates significant traffic.
  • No social engineering or phishing of our team or our customers, and no physical attacks on our infrastructure.
  • Do not use a finding for anything beyond proving it exists, and give us reasonable time to fix it before you publish. We will coordinate disclosure with you, not against you.

The Vulnerability Research Program

The disclosure program covers what we run. The research program covers what we ship. Marmot is MIT licensed and runs as one binary and a Postgres database, which makes it an unusually convenient research target: clone it, read the source, run it, fuzz it, and attack your own instance as hard as you like. The quick start gets you a catalog in a couple of minutes.

Findings in the open source code get fixed in the open, with a GitHub security advisory and a CVE where one is warranted, and security fixes are ported to both the open source project and Marmot Cloud, always. If your research raises a question we can answer, whether something is intended behavior, how a component fits together, ask us at security@marmotdata.io and we will actually answer.

Safe harbor

If you follow the rules on this page, your research is authorized. We will not pursue legal action against you or report you to law enforcement for good-faith research conducted under this program, and if a third party raises it, we will make clear that you were acting with our authorization. This does not permit breaking laws that protect anyone other than us.

Thank you

Marmot got better because people ran it and told us plainly where it fell short. Security research is that same feedback loop with higher stakes, and we are glad to have you in it. We are still getting the company off the ground, so this is not a paid program yet, but good findings do not go unanswered: we send swag and merch scaled to impact, and we credit reporters by name in the advisory and the release notes if they want to be.