Snowflake’s Vulnerability Disclosure Policy
Overview
Snowflake Inc. (“Snowflake”) is committed to the security and privacy of our customers and their data. We believe that collaborating with the security community and supporting coordinated vulnerability disclosures are essential to maintaining a strong security posture and achieving our security goals.
Snowflake’s Vulnerability Disclosure Policy (VDP) covers the requirements for researchers who participate in our vulnerability disclosure program, sometimes referred to as our “bug bounty” program, and outlines the processes by which we handle the reporting, acknowledgment, and resolution of new security vulnerabilities discovered in Snowflake products, services, and systems**, owned or hosted by or on behalf of Snowflake**. The objective of this policy is to ensure a structured, transparent, and coordinated approach to report security vulnerabilities, often in collaboration with external security researchers and the broader security community.
Our VDP is an essential tool for fostering a proactive and responsible approach to security. It ensures that vulnerabilities are addressed promptly and effectively, minimizing risk and safeguarding our systems and customers' data. Additionally, this policy helps promote a culture of collaboration between Snowflake and the security research community, allowing us to work together to continuously improve the security of our platform.
By providing clear and consistent guidelines for reporting and resolving vulnerabilities, Snowflake’s VDP enhances the overall security of our systems and strengthens the trust between Snowflake and the cybersecurity community.
How to Report a Vulnerability
We partner with HackerOne to run a private vulnerability disclosure program to work with security researchers to address vulnerabilities in a secure and coordinated manner. If a researcher discovers a security vulnerability in any Snowflake products, services, and systems, owned or hosted by or on behalf of Snowflake, we highly encourage it to be reported to us. Researchers’ contributions help us identify and resolve potential issues before they can be exploited.
To report a security vulnerability:
- Submit a Report: Researchers already invited to participate in our private vulnerability disclosure program should submit a detailed report of the issue they discovered through their HackerOne account. If a researcher has not received an invitation to participate in our vulnerability disclosure program, please submit a request by clicking “Contact Security Team” on the Snowflake HackerOne page.
- Include Key Information: Researchers must provide a comprehensive summary of the vulnerability, including:
- The target (e.g., product, website, or service affected).
- Steps to reproduce the vulnerability.
- Any tools or artifacts (e.g., scripts, software, or network traffic) used during discovery.
- Screen captures or other supporting documentation to help illustrate the issue and how you identified the vulnerability.
- Provide Your Contact Information: Researchers must include their email address at the bottom of the report form, so we can make contact for further details or updates.
We appreciate all researchers’ efforts to help us keep Snowflake secure, and thank researchers for their contribution to the security of our platform.
For Password or Account Issues
If you are a customer and are experiencing issues with your Snowflake account or password, please contact Snowflake Support directly via https://support.snowflake.com.
Snowflake Safe Harbor Policy
At Snowflake, we support the protection of organizations and researchers engaged in Good Faith Security Research to help identify security vulnerabilities in Snowflake products, services, and systems. We consider Good Faith Security Research to be an authorized activity, and will not pursue legal action against parties conducting research in accordance with this policy. Good Faith Security Research is accessing a Snowflake system for the purposes of good faith testing, investigation, and/or confirmation of a security flaw or vulnerability, where such activity is carried out in a manner designed to avoid any harm to Snowflake, its customers, or the public, uses reasonable practices, and complies with this policy. Good Faith Security Research may include bypassing technological measures Snowflake uses to protect applications and services.
Specifically, for activities in accordance with this policy that we determine to be Good Faith Security Research, the following Safe Harbor Policy protections will apply:
- No Legal Action for Good Faith Security Research: We will not bring or voluntarily assist with legal action against researchers for engaging in conduct that we determine in our sole discretion constitutes Good Faith Security Research.
- Support if Legal Action is Taken: If a third party brings legal action against you for activities we determine to be Good Faith Security Research, we will take reasonable steps to acknowledge that your activities were conducted in good faith and were intended to improve security. For the avoidance of doubt, we will not be obligated, under any circumstances, to indemnify or defend you in the event of legal action related to your activities.
We ask that you contact Snowflake Security before engaging in any activity that you believe may fall outside the scope of Good Faith Security Research or that may not be explicitly addressed by this policy. Snowflake reserves the right to determine, in its reasonable and sole discretion, whether a researcher’s activity qualifies as Good Faith Security Research.
Important Considerations:
- Snowflake's Safe Harbor protection only applies to security research conducted within the scope of Snowflake products, services, and systems owned or hosted by or on behalf of Snowflake, as set forth within this VDP. It does not include any activity intentionally or unintentionally conducted in out-of-scope systems (including those listed at the end of this Policy) or customer environments, or that results in any adverse impact to customers, including, but not limited to, actions that result in the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to our customers’’ data.
- We cannot authorize or provide Snowflake Safe Harbor Policy protections for research conducted on third-party systems or infrastructure, and third-party entities are not bound by this policy.
- Activities conducted by researchers must be reasonable and comport with standard and accepted research practices. Actions we find to be malicious, reckless, or negligent will not be considered Good Faith Security Research and are not protected by the Safe Harbor Policy.
By ensuring that research is conducted with good intent and in a responsible manner, we aim to promote a safe and secure environment for all Snowflake customers, users, and stakeholders.
Research and Testing Guidelines
During research or testing of Snowflake’s systems, researchers must adhere to the following guidelines to ensure proper tracking and identification of research activity:
- Use Your HackerOne Email Alias
When submitting reports or performing testing, researchers must use their HackerOne email alias (e.g., [email protected]) or the provided credentials from the top-right corner of the Snowflake program page. This ensures that the researcher’s activity is correctly linked to their HackerOne account.
- Include Identifiers in Requests
To help identify researcher’s activity, researchers should include relevant identifiers in the HTTP headers and requests whenever possible. Recommended identifiers include:
- h1
- hackerone
- researcher
- bugbounty
These identifiers help us track and associate the researcher’s activity with the correct program and report, improving the efficiency of the review process.
Snowflake’s Vulnerability Disclosure Terms
By submitting a vulnerability report, researchers agree to the following terms. Compliance with all terms is necessary to be considered for a reward under the VDP.
1. Reporting Vulnerabilities
- Confidentiality: Researchers must report any discovered security vulnerabilities to Snowflake via HackerOne without disclosing any information publicly. Researchers are expected to keep the details of the vulnerability confidential until it is resolved by Snowflake and communicated to customers, if applicable.
- Detailed Reports: Researchers are required to provide as much detail as possible in their submission to help Snowflake’s security team reproduce the issue. Reports that are insufficiently detailed to allow for reproduction of the vulnerability will not be eligible for reward consideration.
- Submissions Outside of HackerOne: Researchers are strongly encouraged to report vulnerabilities through Snowflake’s vulnerability disclosure program via authenticated HackerOne research accounts; however, if a researcher wants to report a vulnerability through other means, such reports can be submitted to [email protected]. Please note that reports submitted outside of HackerOne are still subject to this policy, but are ineligible for reward bounties, recognition, or other considerations.
2. Snowflake’s Response Time
- Initial Response: Snowflake will aim to acknowledge receipt of the vulnerability report within three (3) business days from the date the researcher first submits the vulnerability.
3. Disclosure Process
- No Public Disclosure Before Resolution: Researchers may not publicly disclose details of the vulnerability until Snowflake has resolved the issue and communicated any necessary information to customers. Snowflake will work with the researcher on a mutually agreed-upon disclosure plan and timeline.
- Timeline for Disclosure: Within thirty (30) days of the initial report, Snowflake will propose a timeline for public disclosure. If additional time is needed to resolve the vulnerability, Snowflake may extend the timeline for disclosure by up to sixty (60) days with notification to the researcher.
4. Researcher Responsibilities
- Authorized Access: Researchers are only permitted to access or modify data that belongs to them (e.g., their own Snowflake account). If necessary for testing, researchers must sign up for a free trial account.
- No Harmful Activity: Researchers are prohibited from destroying, stealing, modifying, damaging, or otherwise jeopardizing the privacy or integrity of Snowflake’s customers’ data or any Snowflake data.
- Avoiding Sensitive Data: Researchers should avoid accessing sensitive or personal information during their research whenever possible. If accessing such data is required to confirm the vulnerability, researchers must:
- Limit the data accessed to the minimum amount necessary to confirm the vulnerability.
- Inform Snowflake immediately if any sensitive or personal information is accessed.
- Data Protection: If sensitive or personal data must be stored during research, researchers must ensure that reasonable protections, such as encryption, are applied to the data during the time it is stored.
- No Unauthorized Use of Data: Researchers agree not to save, share, exploit, or use any sensitive or personal information they access during their research, except for the purpose of reporting the vulnerability to Snowflake under the terms of this policy.
5. Legal Compliance
- Legal and Contractual Compliance: By making a submission, researchers certify that their actions comply with all applicable laws and contractual obligations. Researchers also confirm that they are not acting on behalf of governmental or criminal entities.
6. Reward Eligibility
-
Additional Terms: To be eligible for a reward under Snowflake’s vulnerability disclosure program, a researcher may be required to agree to additional terms, which will be provided by Snowflake prior to the researcher’s receipt of an applicable reward.
-
Ineligibility: Researchers are not eligible for a bug bounty reward under the VDP if:
- A resident of any countries under U.S. sanctions or any other country that does not allow participation in this type of program;
- Under the age of 14;
- Currently an employee of Snowflake, or have been an employee within the past two years, or are an immediate family (parent, sibling, spouse, or child) member of such employee or former employee;
- Currently perform services for Snowflake in an external staff capacity that requires access to the Snowflake network, such as agency temporary worker, vendor employee, business guest, or contractor;
- Fail to comply with all of Snowflake’s VDP terms as reasonably determined by Snowflake in its sole discretion.
Prohibited Activities
The following activities are expressly prohibited under Snowflake’s Vulnerability Disclosure Program:
- Abuse of Support Features: For researchers using a trial Snowflake account, the 'Raise a Support Ticket' and 'Provide Feedback' features are out of scope. Any accounts detected abusing these features will be locked.
- Physical Attacks: Engaging in any form of physical attack against Snowflake’s or its vendors’ employees, customers, contractors, service providers, offices, infrastructure, or data centers.
- Misuse of Sensitive or Personal Information: Saving, sharing, exploiting, or misusing sensitive or personal information outside the scope of this policy.
- Automated Security Testing: Performing automated security testing against Snowflake applications or servers. Tools like nmap and Burp Suite are allowed for manual research, but reports generated by automated tools are not eligible for the program, as Snowflake already conducts this testing in-house.
- Testing on Customer Instances: Conducting research on any of Snowflake’s customers’ instances.
- Modifying Test Environment Network Policies: Configuring network policies on Snowflake's test environments. These environments must remain accessible to all researchers in the program.
- Social Engineering: Engaging in social engineering tactics such as phishing, vishing, or smishing aimed at Snowflake’s or its vendors’ employees, customers, contractors, vendors, or service providers.
- Unsolicited Bulk Messaging (Spam): Attempting to pursue vulnerabilities through the sending of unsolicited bulk messages (i.e., spam).
- Compromising Accounts: Attempting to compromise or gain unauthorized access to any Snowflake customer account, employee account, or vendor account. Researchers must not intentionally access another user's account or data.
- Malware: Knowingly posting, transmitting, uploading, linking, or sending malware to Snowflake or its vendors’ employees, customers, contractors, service providers, infrastructure, or data centers.
- Mass Account Creation: Creating mass accounts for testing against Snowflake applications and services.
- Brute Force Testing: Conducting "brute force" testing to determine if rate-limiting mechanisms are in place for specific APIs or functionalities.
- Acceptable Use Policy Violations: Engaging in activities that violate Snowflake's Acceptable Use Policy.
- Premature Public Disclosure: Disclosing any vulnerability to the public before it has been resolved or without Snowflake’s express written permission.
- Illegal Activities: Researchers are prohibited from engaging in any illegal activity related to research under the VDP.
Out-of-Scope Issues
The following issues may be submitted to Snowflake’s Vulnerability Disclosure Program, but are not qualified for a reward:
- CSRF/XSRF on Unauthenticated Pages: Issues such as Cross-Site Request Forgery (CSRF) or Cross-Site Script Forgery (XSRF) on unauthenticated pages (e.g., the login page) or logout functionality.
- Lack of Rate Limiting or Load Testing Issues: Issues related to the lack of rate limiting on specific APIs or any issues falling under load testing types of vulnerabilities.
- Non-Sensitive Cookies Missing Security Flags: Non-session cookies missing the Secure or HttpOnly flags, unless they directly relate to sensitive data or security concerns.
- Denial-of-Service (DoS) Vulnerabilities: Any vulnerabilities that can cause a Denial-of-Service (DoS), preventing the application or service from functioning properly.
- Application or Server Error Messages: Any vulnerabilities related to error messages generated by the application or server that do not expose sensitive information.
- Out-of-Date 3rd-Party Libraries: Issues involving the use of outdated third-party libraries without a demonstrated proof of exploitability (i.e., no actual vulnerability or attack vector).
- Missing HTTP Security Headers: Absence of security-related HTTP headers such as:
- X-Frame-Options
- Content-Security-Policy
- Strict-Transport-Security
- X-Content-Type-Options
- X-XSS-Protection
- Email Configuration Issues (SPF, DMARC, etc.): Issues related to email configurations like SPF, DMARC, or other email setup-related problems.
- Password or Account Recovery Policies: Issues concerning password recovery policies such as reset link expiration times or password complexity requirements.
- HTTP Error Codes (e.g., 404): Issues related to HTTP 404 errors or other non-200 HTTP response codes that do not indicate a security vulnerability.
- Version Number or Banner Disclosure: Public disclosure of version numbers or technology stack information, typically found in HTTP headers or server banners.
- Disclosure of Known Public Files/Directories: Reporting files or directories that are publicly accessible by design, such as robots.txt or other known public files.
- Lack of DNSSEC: Absence of DNSSEC (DNS Security Extensions).
- Attacks Requiring MITM or Physical Access: Vulnerabilities that require a Man-In-The-Middle (MITM) attack or physical access to the user’s device.
- SSL Configuration Issues: Vulnerabilities related to SSL/TLS configurations, such as:
- Insecure cipher suites
- SHA-1 certificates
- Vulnerabilities like BEAST or CRIME
- Lack of Perfect Forward Secrecy (PFS)
- Enabled HTTP TRACE or OPTIONS Methods: HTTP TRACE or OPTIONS methods enabled on the server, unless they can be directly exploited in a meaningful way.
- Clickjacking on Pages Without Authentication or Sensitive State Changes: Clickjacking vulnerabilities on pages that do not involve authentication or any sensitive state changes.
- End-of-Life Browsers/Platforms: Vulnerabilities that only affect end-of-life browsers or platforms that are no longer widely used or supported.
- Autocomplete or Save Password Functionality: Presence of autocomplete or save password functionality in application forms, where no sensitive information is exposed.
- Previously Known Vulnerable Libraries: Issues related to previously known vulnerable libraries that do not include a working Proof of Concept (PoC) or exploitation scenario.
- Any Activity Leading to DoS: Any actions that could cause a Denial-of-Service (DoS), disrupting or degrading Snowflake's services.
- Content Spoofing or Text Injection: Content spoofing or text injection vulnerabilities that do not directly affect user security or the integrity of data.
- Information Disclosure from Snowflake Customers: Disclosures related to credential leaks or other sensitive information originating from Snowflake’s customers.
- Credentials Provided for Testing: Reporting on credentials provided specifically for HackerOne testing purposes.
Out-of-Scope Domains
The following domains are not qualified for a reward under Snowflake’s Vulnerability Disclosure Program:
- careers.snowflake.com
- developer.snowflake.com
- developers.snowflake.com
- events.snowflake.com
- event.snowflake.com
- global.snowflake.com
- go.snowflake.com
- go.snowflake.net
- guides.snowflake.com
- info.snowflake.com
- investors.snowflake.com
- learn.snowflake.com
- lift.snowflake.com
- lifttest.snowflake.com
- liftdev.snowflake.com
- partnerdemandcenter.snowflake.com
- training.snowflake.com
- qa-training.snowflake.com
- reply.snowflake.com
- resources.snowflake.com
- social.snowflake.com
- status.snowflake.com
- usergroups.snowflake.com
- www.snowflake.com
Reward Structure:
Since Snowflake's Bug Bounty program is private, only invited users can access the program's reward structure and other details.
If you're already a participant in the program, you can view the details directly by logging into your authenticated HackerOne account(s).
Thank you for helping keep Snowflake and our customers safe!