Vulnerability Disclosure Policy
Vulnerability Disclosure Policy
0. Informal Summary / tl;dr
1. Introduction
Stackable is committed to ensuring the safety and security of our company, users, and customers by protecting their information. This policy provides clear guidelines for security researchers conducting vulnerability discovery activities and outlines our preferences for submitting discovered vulnerabilities. It describes the systems and types of research covered, how to send vulnerability reports, and the expected timeline for public disclosure. We encourage you to contact us to report potential vulnerabilities in our systems and products.
For the most up-to-date information on how to report security vulnerabilities, please refer to our security.txt file.
2. Authorisation
If you make a good faith effort to comply with this policy during your security research, we will consider your research authorised. We will work with you to understand and resolve the issue quickly, and Stackable will not recommend or pursue legal action related to your research. Should legal action be initiated by a third party against you for activities conducted in accordance with this policy, we will make this authorisation known.
3. Scope
We welcome reports for vulnerabilities in the products we produce e.g. Stackable Data Platform and for Stackable projects hosted on GitHub.
This policy applies to Stackable-managed systems that are accessible from the Internet. This includes our primary domains listed below, including their subdomains unless otherwise stated:
*.stackable.tech
*.stackable.de
The following domains are out of scope and no explicit or implicit authorisation is given for assets in these domains to be tested:
*.infra.stackable.tech
*.stackable.site
*.stackable.build
Internal-only services and third-party services not under a Stackable subdomain are out of scope. Vulnerabilities found in systems from our vendors should be reported directly to the vendor according to their disclosure policy. Stackable grants no authorisation for testing its software deployed by our users and customers.
4. Test Methods
The following test methods are not authorised:
Network denial of service (DoS or DDoS) tests or other tests that impair access to or damage a system or data.
Physical testing (e.g., office access, open doors, tailgating).
Social engineering (e.g., phishing, vishing).
Any other non-technical vulnerability testing.
Destructive testing of any kind, including tests that result in the loss of data.
5. Non-Qualifying Findings
The following types of findings are considered out of scope for this policy:
Reports generated by automated tools without manual verification or explanation of the vulnerability’s relevance.
False positives from automated scans, such as reporting benign data (e.g., git hashes) as personally identifiable information (PII).
Automated scans for CVEs using typical vulnerability scanners, as we conduct this monitoring ourselves.
DoS/DDoS (Denial of Service) attacks.
Brute-force attacks.
Password-stuffing attacks.
Social engineering related attacks (e.g., phishing, vishing, smishing).
Clickjacking/UI-redressing.
Tab-Nabbing or other rel=”noopener” bugs.
Vulnerabilities reliant on out-of-date browsers/software.
Mixed content warnings.
Missing or misconfigured security-related HTTP headers that don’t directly lead to a vulnerability.
Missing cookie flags that do not directly lead to a vulnerability.
Web Cache Poisoning.
Content Spoofing.
Request Smuggling.
CORS Misconfiguration.
SPF, DKIM, and DMARC records and flags.
Server banners.
Expired SSL certificate issues.
Absence of rate limiting for authentication and APIs.
6. Automated Tools Guidelines
Automated tools should not generate more than 5 requests per second to avoid negatively impacting the performance and availability of our services.
Results from automated tools must be explained and represent a relevant vulnerability.
7. Vulnerability Handling Process
Our vulnerability handling process consists of the following steps:
7.1 Report
To report a security vulnerability affecting a Stackable product, solution, or infrastructure component, please contact us using the methods described in our security.txt file. We aim to respond to incoming reports within five business days.
7.2 Analysis
We will investigate and attempt to reproduce the vulnerability. We may request additional information from you during this phase.
The result of this phase may be that we deem a report as not a valid vulnerability.
7.3 Handling
We will perform internal vulnerability handling. During this time, we will maintain regular communication with you to provide updates on the status and ensure that our position is understood.
7.4 Disclosure
After handling a vulnerability in one of our products (not our infrastructure) we will distribute the fix using our existing customer notification processes. This may include direct customer notification or the public release of a security advisory containing all necessary information on our website.
Include the reporter in our “Hall of Thanks” page if desired.
8. Guidelines
Under this policy, “research” means activities in which you:
Notify us as soon as possible after discovering 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 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.
Provide us a reasonable amount of time to resolve the issue before disclosing it publicly.
Once you’ve established that a vulnerability exists or encounter any sensitive data (including personally identifiable information, financial information, or proprietary information or trade secrets of any party), you must stop your test, notify us immediately, and not disclose this data to anyone else.
9. What you can expect from us
We will keep each vulnerability report confidential to the extent permitted by law.
We will not pass on personal data to third parties without your explicit consent.
We will provide feedback on every vulnerability report made.
We will not pursue criminal charges against you as long as you comply with this policy, unless recognizable criminal intentions are evident.
We will keep you informed of developments and the remedy for the vulnerability throughout the process.
In the event of a CVE publication, we will coordinate disclosure with all involved parties (e.g., researchers, vendors).
Within five business days, we will acknowledge receipt of your report via email.
We will provide status updates as relevant information becomes available.
After completion of a coordinated vulnerability disclosure process, if desired, we will publish your name/alias and a desired reference on our acknowledgment website (Hall of Thanks).
10. What we would like to see from you
The vulnerability found was not abused, meaning no damage was caused beyond the reported vulnerability.
No attacks (such as social engineering, spam, (distributed) DoS, DDoS, “brute force” attacks, malware, viruses, etc.) were carried out against IT systems or infrastructures.
No manipulation, compromise, or modification of possible systems or data of third parties was carried out.
No tools for exploiting vulnerabilities have been offered for a fee or free of charge that third parties could use to commit crimes.
Vulnerability reports are not results of automated tools or scans without supporting documentation. These are not valid vulnerability reports.
The vulnerability report relates to previously unknown information. Your report will be checked for vulnerabilities that have already been fixed, but they do not qualify for further processing as part of the CVD process.
Do not publicly disclose the vulnerability until we had enough time to remedy it
Do not submit a high volume of low-quality reports.
11. Report content
A vulnerability report should contain the following information if possible:
The name of the product and the tested version number.
A simple description (including screenshots or other illustrations if necessary) showing how the vulnerability was discovered (including any tools used) and the steps (or scripts) needed for us to reproduce the vulnerability.
An informal declaration of consent to include a name/alias on our acknowledgment website (Hall of Thanks) if desired.
The report should be in English or German if possible.
12. Change History
2025-02-25 – Version 1.0 – Initial version of the Vulnerability Disclosure Policy