Skip to content

Security: firebolt-db/firebolt-core

Security

SECURITY.md

Firebolt Analytics Responsible Disclosure Security Policy

Reporting a Vulnerability

We prioritize the security of Firebolt Core and value responsible vulnerability reporting. To ensure efficient handling of security issues, we require all reports to be submitted to [email protected].

Please DO NOT open public issues for security problems. Reports made through public channels will be closed, and you will be directed to this policy.

Scope

This security policy exclusively applies to vulnerabilities within Firebolt Core - our free, self-hosted SQL engine, which powers Firebolt's high-performance data warehouse - as distributed in this specific firebolt-core repository https://github.com/firebolt-db/firebolt-core).

This policy does NOT apply to Firebolt's managed SaaS offerings or any other Firebolt products.

We are specifically interested in:

  • Software crashes due to vulnerabilities such as buffer overflows, use-after-free
  • Bypassing access controls such as S3 credentials to read external data

We WILL NOT ACCEPT reports concerning:

  • Other repositories within this GitHub organization or account.
  • External projects, dependencies, or third-party services.
  • Vulnerabilities in systems or infrastructure not directly controlled by this repository.
  • Social engineering, phishing, or physical security vulnerabilities.
  • If you identify a vulnerability outside the defined scope that may impact Firebolt’s security, please contact us at [email protected]. We will review such reports on a case-by-case basis.
  • Please note that Firebolt does not access or process any data stored or processed in your self-hosted Firebolt Core deployment. Only information submitted as part of a vulnerability report is received by Firebolt.

Out of Scope and Report Rejection Criteria

To maintain efficiency and focus on genuine security risks, the following types of reports are considered out of scope and will be rejected:

  • Denial-of-Service (DoS) vulnerabilities that cannot be demonstrated to impact production systems at a significant scale.
  • Vulnerabilities requiring privileged access, local access, or specific user interaction (unless a realistic attack scenario is provided).
  • Reports based solely on theoretical risks without a working proof of concept.
  • Best practice suggestions or configuration recommendations without a demonstrated, exploitable vulnerability.
  • Vulnerabilities that have already been reported.
  • Reports generated by automated tools, including, but not limited to, basic web scanners (e.g., Nikto, Acunetix, etc.). We require manual verification and analysis.
  • Vulnerabilities that rely on outdated software or configurations that are explicitly documented as unsupported.
  • Reports from countries under embargo.

Requirements for a Valid Report

To ensure your report can be effectively assessed, it must include the following:

  1. A clear and concise description of the vulnerability.
  2. A working Proof of Concept (PoC) that demonstrates the vulnerability's exploitability. This should include:
    • The exact steps to reproduce the vulnerability.
    • The specific input or conditions required.
    • The observed (vulnerable) behavior.
    • The expected (secure) behavior.
  3. A clear explanation of the potential security impact if the vulnerability is successfully exploited. This should include:
    • The affected data or systems.
    • The potential consequences (e.g., data loss, unauthorized access, code execution).
  4. Crash logs and stack traces that helps us identify the location/origin of the bug.
  5. Suggested Remediation - If possible, provide a suggestion for how the vulnerability could be fixed or mitigated.
  6. The specific version(s) of the code in this repository that are affected by the vulnerability.
  7. No Public Disclosure:Confirmation that the vulnerability has not been, and will not be, disclosed publicly until we have had a reasonable opportunity to address it.

Reports lacking the required information may be deemed invalid and closed.

Our Response Process

  1. Acknowledgement: We will acknowledge receipt of your report within 3 business days.
  2. Triage: We will triage the report to assess its validity and severity.
  3. Investigation: We will investigate the vulnerability and attempt to reproduce it.
  4. Communication: We will communicate our findings and next steps to you, which may include:
    • Requesting further information.
    • Informing you that the report is invalid or out of scope.
    • Providing a timeline for remediation.
  5. Resolution: We will work to address the vulnerability.
  6. Depending on our disclosure policy, we may publicly disclose the vulnerability after a fix has been released. If we do, we will credit you for the finding, if you wish.

Legal

  • Reporting a vulnerability in accordance with this policy grants us the right to use your report for the purpose of addressing the vulnerability. By submitting a vulnerability report (including any code, patches, proof-of-concept code, or other materials), you acknowledge and agree that all intellectual property rights in and to such submissions are assigned to Firebolt in accordance with the Firebolt Core License Terms.
  • We reserve the right to reject any report that does not comply with this policy.
  • Personal data submitted as part of a vulnerability report will be processed in accordance with our privacy policy and applicable data protection laws. Please avoid including unnecessary personal data in your submission.

Safe Harbor for Security Research

If you act in good faith to comply with this Policy, Firebolt will not initiate legal action against you or ask law enforcement to investigate you for activities reasonably necessary to identify and report vulnerabilities, including reverse engineering, decompiling, or similar activities, provided such activities are conducted in accordance with this Policy.

There aren’t any published security advisories