Skip to content

Security: bleemeo/bleemeo-python

Security

SECURITY.md

Security Policy

Bleemeo takes the security of our software, services, and the data of our users seriously. This policy applies to every project under the bleemeo GitHub organization, including the SaaS platform, Glouton, SquirrelDB, and our SDKs.

Thank you for taking the time to report issues responsibly.

Reporting a vulnerability

Please use one of the following channels, in order of preference.

1. GitHub private vulnerability reporting (preferred)

Each Bleemeo repository has private vulnerability reporting enabled. From the affected repository, go to the Security tab and click Report a vulnerability, or follow GitHub's documentation.

This is the channel we monitor most actively. It keeps the report confidential, lets us draft an advisory alongside the fix, and gives you a clear timeline.

2. Email

If GitHub private reporting is not an option, email security@bleemeo.com.

For sensitive reports, you may encrypt your email with our PGP key.

  • Fingerprint: 496B 6A35 F07B B8FC CC4B C73F 3AAF BBFB F12B 1AB4
  • UID: Bleemeo Security <security@bleemeo.com> (RSA 4096, valid until 2028-08-28)

Download the public key:

Always verify the fingerprint above matches the key you receive before encrypting anything sensitive — never trust a key just because it carries the right email address.

What we do NOT want

  • Do not open public GitHub issues, pull requests, or discussions for security reports.
  • Do not disclose the issue on social media (X, LinkedIn, Bluesky, Mastodon, etc.) before we have published a fix.
  • Do not run destructive tests against our production infrastructure, our customers' environments, or systems you do not own.

What to include in a report

To help us triage quickly, please include as much of the following as you can:

  • A clear description of the vulnerability and its impact.
  • The affected project and version(s) (commit SHA or release tag if possible).
  • Step-by-step instructions to reproduce.
  • A proof of concept (script, payload, screenshot, or video) if you have one.
  • Your environment (OS, runtime, deployment topology).
  • Any mitigations you've already identified.
  • Whether you'd like to be credited, and under what name.

Supported versions

For each open-source project, we issue security fixes for the latest released minor version of the current major version. Older versions may receive backports at our discretion when a fix is low-risk and the impact is severe.

Status What it means
Latest minor of the current major — actively patched.
⚠️ Previous minor — patched only for critical issues.
Older majors — no longer patched. Please upgrade.

The Bleemeo SaaS platform is rolled forward continuously; only the running production version is supported.

Response timeline

We aim to follow this schedule for any valid security report. Times are in business days unless noted.

Step Target
Acknowledge receipt Within 72 hours
Initial assessment Within 7 days
Remediation plan shared Within 30 days
Coordinated public disclosure Ideally within 90 days

If a report ends up taking longer (complex multi-component fix, dependency upstream, etc.), we will keep you informed. We prefer coordinated disclosure, but we will not use the timeline to indefinitely delay disclosure of an issue that has been responsibly reported.

Safe harbor

We support good-faith security research. If you:

  • Make a good-faith effort to avoid privacy violations, destruction of data, and disruption of our services;
  • Only interact with accounts and data you own, or have explicit permission from the account holder to access;
  • Give us reasonable time to investigate and remediate before public disclosure;
  • Do not exploit the issue beyond what is necessary to demonstrate it;

…then we will not pursue or support any legal action against you for the research itself, and we will work with you in good faith to resolve the issue.

Bleemeo does not currently operate a paid bug bounty program. We will, however, credit you publicly (with your consent) in the acknowledgments below and in the relevant GitHub Security Advisory.

Out of scope

The following are generally not considered security vulnerabilities for the purpose of this policy:

  • Denial-of-service or volumetric attacks against our infrastructure.
  • Social-engineering attacks against Bleemeo employees, customers, or partners.
  • Physical attacks against our offices, data centers, or hardware.
  • Vulnerabilities in third-party dependencies that are already publicly known and have no Bleemeo-specific exploit path.
  • Reports generated solely by automated scanners with no demonstrated impact.
  • Missing security headers, weak cipher suites, or similar best-practice findings without a concrete exploit.
  • Self-XSS and issues that require an already-compromised user environment.

When in doubt, report it — we'd rather assess and decline than miss a real issue.

Acknowledgments

We thank the following researchers for responsibly reporting issues to Bleemeo.

No entries yet — be the first.

There aren't any published security advisories