Introduction
We take security seriously. If you believe you have discovered a potential security vulnerability in one of our products, we encourage you to discreetly report it, via the dedicated form below, quickly and responsibly to us.
This program is intended to give security researchers clear guidelines for conducting vulnerability discovery activities and to convey our preferences in how to submit discovered vulnerabilities to us.
This program describes what systems and types of research are covered under this program, how to send ScyllaDB vulnerability reports, and what timelines to expect from our end.
ScyllaDB may modify the terms of this Bug Bounty Program from time to time and such updated terms, once posted on ScyllaDB website, shall govern. We recommend that you periodically review the terms, to see if any changes were introduced as reflected in the “Last Updated” date hereinabove.
This program covers security vulnerabilities only. Non-security issues – including general bugs, performance problems, feature requests, or usability feedback – are out of scope for this program and will not be reviewed or rewarded under it. Non security issues for open source components can instead be filed directly as a GitHub issue in the relevant repository (see “Open Source Security Findings” below for security-specific findings).
Acceptance
If you make a good-faith effort to comply with this program during your security research, we will consider your research to be accepted. We will work to understand and resolve the issue quickly.
Guidelines
Under this program, “research” means activities in which you:
- Notify us as soon as possible after you discover a real or potential security issue.
- Make every effort to avoid privacy violations, degradation of user experience, disruption to production systems, and destruction or manipulation of data.
- Only use exploits to the extent necessary to confirm a vulnerability’s presence.
- Do not use an exploit to compromise or exfiltrate data, establish persistent command line access, or use the exploit to pivot to other systems.
- Do not submit a high volume of low-quality reports.
Once you’ve established that a vulnerability exists or encounters any sensitive data (including personally identifiable information, financial information, proprietary information, or trade secrets of any party), you must stop your test, notify us immediately, and not disclose this data to anyone else.
Scope
Some of our systems may be eligible for bounties. Those can be successfully shown to compromise the confidentiality, integrity, or availability of information relating to our clients and our secrets will be considered.
Please find below the current list of bounty-eligible systems (such list may change from time to time at our sole discretion).
ScyllaDB Products
Out of Scope
ScyllaDB web site domains and any related subdomains are
out of scope.
The following activities are out of scope for the ScyllaDB Bug Bounty Program. Conducting any of the activities below will result in disqualification from the program permanently.
- Targeting assets of ScyllaDB’s customers
- Any vulnerability obtained through the compromise of ScyllaDB customer or employee accounts
- Any Denial of Service (DoS) attack against ScyllaDB products or ScyllaDB customers
- Social engineering of ScyllaDB employees, contractors, vendors, or service providers
- Knowingly posting, transmitting, uploading, linking to, or sending malware
- Pursuing vulnerabilities which send unsolicited bulk messages (spam)
In case a vulnerability report will be submitted about an item that is included in the above list, ScyllaDB will not review and the report will be rejected.
Reporting a Suspected Vulnerability
We accept vulnerability reports via this Google form only.
Each report is cataloged, dated, and scrutinized for its scope and risk level.
To enable us to respond more efficiently to your report, kindly provide any relevant supporting materials (such as proof-of-concept code, tool output, etc.) that would aid us in comprehending the nature and severity of the vulnerability.
Reported vulnerabilities of a the same reported issue
previously, will be rejected.
Open Source Security Findings
Several ScyllaDB products are distributed as open source software hosted on GitHub (for example, ScyllaDB Drivers, ScyllaDB Operator, and ScyllaDB Monitoring Stack). For security vulnerabilities discovered in these open source repositories:
- You must still submit the finding via the Google form as described above, so it can be triaged and tracked under this program.
- In addition, you should open a corresponding issue in the relevant ScyllaDB GitHub repository, labeled as a security finding, so it is tracked alongside the project’s other open issues.
Do not include exploit details, proof-of-concept code, or other sensitive technical detail in the public GitHub issue. The GitHub issue should describe only that a security review is in progress (e.g., affected component and general area of concern); full technical detail belongs in the private form submission until ScyllaDB confirms it is safe to disclose.
- If a reported issue is later confirmed as a valid vulnerability, ScyllaDB will coordinate with you on the appropriate disclosure timeline before any additional detail is added to the public GitHub issue.
- Reports concerning open source components remain subject to all other guidelines, scope limitations, and SLAs described in this policy.
SLA for Evaluation By ScyllaDB
ScyllaDB is committed to being responsive and keeping you informed of our progress as we investigate and/or mitigate your reported security concerns. You will receive a non-automated response to your initial contact as quickly as possible, confirming receipt of your reported vulnerability and assigning you a tracking number. The amount of time required to validate a reported vulnerability can change per case, and it depends on the complexity and severity of the issue. We make every effort that all reports and answers will be provided no longer than 120 days.
The findings would be categorized according to the Risk Analysis by level
- Critical: This is dangerous and immediate safety measures must be taken to avoid any loss of our most confidential data.
- High: This risk isn’t acceptable either. It needs immediate checks and necessary measures should be taken to minimize the loss or the damage of data.
- Medium: This is the period where we cannot overlook the damage that has already been caused. Proper planning and steps should be taken to control further loss or damage.
- Low: Low risks are acceptable and can be rectified through proper security measures. In situations where the damage has already been taken the effect is really low.
Disclosure
ScyllaDB requests that you do not publicly disclose any information regarding the vulnerability or exploit the issue until it has had the opportunity to analyze the vulnerability, respond to the notification, and notify key users, customers, and partners.
Confirmation of Non-Vulnerabilities: If the issue cannot be validated, or is not found to originate in an ScyllaDB product, this will be shared with you.
