Slack Technologies, LLC, a Salesforce company

Over $12M in bounties awarded across all our H1 Bug Bounty programs since 2015!

At Slack, a Salesforce company, Trust is our #1 value and we take the protection of our customers' data very seriously. As a result, we encourage responsible reporting and disclosure of any vulnerabilities that may be found on our websites, APIs, or applications.

Slack is committed to working with security researchers to verify and address any potential vulnerabilities that are reported to us. If you want to help us make our products safer with the possibility of a reward in the process, you are in the right place!

Please review these terms before you test and/or report a vulnerability. Slack pledges not to initiate legal action against researchers for penetrating or attempting to penetrate our systems as long as they adhere to this policy.

Eligibility for the Bug Bounty Program

Under our Bug Bounty Program, qualified individuals are encouraged to submit bug reports that detail existing vulnerabilities in certain in-scope Salesforce products and services. In certain circumstances, Salesforce may grant monetary rewards to those who submit vulnerability reports.

We are happy to thank every individual researcher who submits a vulnerability report helping us improve our overall security posture at Slack. However, only those researchers that meet the following criteria may be eligible to receive a reward. Some of the requirements to participate in the Bug Bounty Program include:

• You must be the first reporter of a vulnerability associated with a participating service (we will also not reward for a known vulnerability which we are actively fixing)

• You must have personally discovered the vulnerability and you may not report a vulnerability that was discovered by another person (including, and especially, someone who does not qualify to participate in the Bug Bounty Program)

• You must not be employed by Slack, Salesforce, its subsidiaries, or any related entities, currently or in the last 12 months.

• You must comply with this Policy when discovering the vulnerability and submitting the vulnerability report

• Slack or H1 can’t be legally prohibited from rewarding you for any reason

• Non-automated testing is allowed on production Slack infrastructure, preferably using dedicated test teams. Any testing for cross-team vulnerabilities should be conducted using dedicated teams created and owned by the researcher.

Conduct Guidelines

While we encourage you to discover and report to us any vulnerabilities you find in a responsible manner, the following conduct is expressly prohibited and will result in disqualification from the Bug Bounty Program:

• Disclosing any vulnerabilities or suspected vulnerabilities you discover to any other person without explicit Salesforce authorization

• Disclosing the contents of any submission to our program without explicit Slack authorization

• Accessing private information of any person stored on a Slack product or service – You must use test accounts

• Accessing sensitive information (e.g., credentials)

• Performing actions that may negatively affect Salesforce system performance or its users (e.g. Spam, Phishing, Brute force, Distributed Denial of Service (DDoS))

• Conducting any kind of physical attack on Slack personnel, property or data centers

• Social engineering any Slack employee or contractor

• Conduct vulnerability testing of participating services using anything other than test accounts (e.g. Developer or Trial Edition instances)

• Exfiltrating data. Please test only the minimum necessary to validate a vulnerability (we can verify if data exfiltration would be possible from a vulnerability, and will reward with the impact in mind)

• Violating any laws or breaching any agreements in order to discover vulnerabilities

If you are testing a publicly viewable area of Slack (eg. https://success.salesforce.com), please remove any test posts or accounts when you are done and refrain from engaging with actual users.

Our Commitment to Researchers

If you submit a vulnerability report, the Salesforce security team and associated development organizations will use reasonable efforts to:

• Respond in a timely manner, acknowledging receipt of your vulnerability report.

• Investigate and consider your vulnerability report for eligibility under our Bug Bounty Program within 30 days of submission or less.

• Notify you when the remediation or other action regarding the vulnerability has been implemented.

Slack Products/Services In Scope for H1 Security Researchers

The Bug Bounty Program is limited to Slack products as specified within the scope section in HackerOne.

Qualifying Vulnerabilities & Bounties (In Scope)

The decision to grant a reward for a vulnerability report, and the value of a reward (if any), is entirely within Salesforce’s discretion. If we decide to offer a reward for a vulnerability report, the value of the reward will usually be based on the impact and severity of the reported vulnerability.

• You will qualify for consideration for a reward only if you are the first person to responsibly disclose an unknown vulnerability to us in accordance with these policies. The determination of whether you are the first person is solely within our responsibility. Vulnerabilities must also be relevant, exploitable, and well-documented in the vulnerability report. We are more likely to grant a reward if the vulnerability is specific, fixable and not currently exploited against us or our customers.

Our target reward range for different types of vulnerabilities within the published scope. Additional bounty may be awarded on top of these base amounts, as determined by the Bug Bounty Management team.

Vulnerability Severity Definitions

The following vulnerability severity definitions are based on internal Salesforce documentation. These definitional are a work in progress. The goal of adding these definitions to our policy is to:

• Allow more efficient report triage

• Align directly with internal Salesforce vulnerability ranking definitions

• Remove ambiguity and subjective assignment of severity

• Promote fair bounty payments

• Promote researcher satisfaction

If you have feedback and/or suggestions to help us make these more clear and useful, please email your ideas to bugbountymanager@salesforce.com

Critical

• Severity level includes but is not limited to:

  • Vulnerabilities that can compromise the confidentiality, integrity, or availability of production and corporate resources and/or data with limited exploitation difficulty and/or attacker skill.

  • Vulnerabilities that could be easily exploited by a remote or unauthenticated attacker and lead to system compromise and/or exposure of highly sensitive or customer data of any kind without requiring user interaction.

  • Exploitation of a vulnerability that results in a root-level compromise of servers or infrastructure devices.

• Examples include, but are not limited to:

  • External facing remote arbitrary code execution without mitigating circumstances.

  • External facing SQL injection.

  • External facing unintended single tenant or cross tenant information disclosure and/or multi-tenancy break

  • Authentication flaws resulting in arbitrary account compromise.

  • Session management flaws leading to arbitrary account compromise.

  • External facing credential leaks and default credential usage resulting in access to production systems containing customer data.

  • Client and server software and system s susceptible to publicly disclosed and exploited vulnerability.

  • Susceptibility to an external, simply executed, single actor, logic-based attacks resulting in a service outage of one or more critical systems/products.

• Tooling Score Estimates include, but are not limited to:

  • Nessus: Critical (In a small subset of cases)

  • CVSSv3 Temporal Score: 9-10

  • Qualys Severity 5

  • nCircle: 1000+ (Based on risk )

  • PCI Violating Vulnerability: Yes

  • AppDetective: High (Based on risk )

  • Whitehat: Urgent

High

• Severity level includes but is not limited to:

  • Vulnerabilities that can compromise the confidentiality, integrity, or availability of production and corporate resources and data.

  • Vulnerabilities that could be easily exploited by an internal and/or external, authenticated/unauthenticated attacker and lead to system compromise and/or exposure of highly sensitive or customer data without requiring user interaction.

  • Vulnerabilities that allow local users to gain increased privileges.

  • Vulnerabilities that allow unauthenticated remote users to view sensitive information.

  • Susceptibility to an external, simply executed, single actor, logic-based attacks resulting in significant performance degradation of one or more critical systems/products.

• Examples include, but are not limited to:

  • Privilege Escalation

  • External facing Persistent/Stored Cross-Site Scripting (XSS).

  • External facing Cross-Site Request Forgery (CSRF) exposure on sensitive or critical functions.

  • External facing stack traces containing sensitive information exposed to clients.

  • Internal network/system use of weak cryptography that is practically exploitable in a real kill chain without nation-state resources.

  • Internal network/system remote arbitrary code execution without mitigating circumstances.

  • Internal network/system command or SQL injection without mitigating circumstances.

  • Internal network/system exposure of sensitive information.

  • Internal network/system use of default or weak credentials.

  • Client/Server software and/or systems susceptible to publicly disclosed vulnerability.

• Tooling Score Estimates include, but are not limited to:

  • Nessus: Critical/Severe

  • CVSSv3 Temporal Score: 7 - 8.93

  • Qualys: Severity 44

  • nCircle:1000 +

  • PCI Violating Vuln: Yes

  • AppDetective: High

  • Whitehat: Critical

Medium

• Severity level includes but is not limited to:

  • Vulnerabilities that may be more difficult to exploit but could still lead to some compromise of the confidentiality, integrity, or availability of resources, under certain circumstances.

  • Vulnerabilities that could have had a critical or high impact but are less easily exploited based on a technical evaluation of the flaw, or affect unlikely configurations.

  • Susceptibility to external, simply executed, single actor, logic-based attacks resulting in some measurable performance degradation of one or more critical systems/products.

• Examples include, but are not limited to:

  • External unintended internal information disclosure.

  • Internal network/application Cross-Site Scripting (XSS).

  • Internal network/application Cross-Site Request Forgery (CSRF).

  • Internal use of weak cryptography that is practically exploitable in a real kill chain with nation-state resources.

  • Usage of EoL operating systems or software.

  • External facing content spoofing.

• Tooling Score Estimates include, but are not limited to:

  • Nessus: Moderate

  • CVSSv3 Temporal Score: 4 - 6.93

  • Qualys: Severity 34.

  • nCircle: 500 - 999.5.

  • PCI Violating Vuln: No

  • AppDetective: Medium

  • Whitehat: High

Low

• Severity level includes but is not limited to:

  • Vulnerabilities that may be more difficult to exploit but could lead to minimal compromise of the confidentiality, integrity, or availability of resources under unlikely circumstances.

  • These types of vulnerabilities require unlikely circumstances to be able to be exploited, or where a successful exploit would have minimal consequences.

  • Susceptibility to external, simply executed, single actor, logic-based attacks resulting in minor performance degradation of one or more critical systems/products.

• Examples include, but are not limited to:

  • XSS from an authenticated customer admin

  • Internal default pages or content without vulnerabilities such as an Apache server-status page enabled, allowing anyone browsing it to see the information of the server, as well as any request currently being made.

  • Exposure of server config information

  • Use of weak cryptography that is not practically exploitable in a real kill-chain.

  • External Cross-Site Request Forgery (CSRF) exposure on non-sensitive or non-critical functions.

  • Documentation bugs

• Tooling Score Estimates include, but are not limited to:

  • Nessus: Moderate (Informational in nature)

  • CVSSv3 Temporal Score: 0.1 -3.93

  • Qualys: Severity 24

  • nCircle: 1 -499.5.

  • PCI Violating Vuln: No

  • AppDetective: Low 7

  • Whitehat: Low

Qualifying Vulnerability Descriptions

| Category | Description |

| --- | --- |

| Remote Code Execution | CWE-94: AKA "Arbitrary Code Execution". Describes a security bug that allows an attacker to execute arbitrary commands or code on a target machine or in a target process. The exploit PoC may include many other vulnerability types, but ultimately the result is p0wnage of the server(s) and/or environment. [src: https://en.wikipedia.org/wiki/SQL_injection] |

| Disclosure of Credit Card data | CWE-359: This is self-explanatory. Any security bug which allows disclosure of credit card information to an unauthorized user or system qualifies as Disclosure of Credit Card Data |

| SQL Injection | CWE-1027: SQL injection is a code injection technique in which nefarious SQL statements are inserted into an entry field for execution (e.g. to dump the database contents to the attacker). SQL injection must exploit a security vulnerability in an application's software, for example, when user input is either incorrectly filtered for string literal escape characters embedded in SQL statements or user input is not strongly typed and unexpectedly executed. SQL injection is mostly known as an attack vector for websites but can be used to attack any type of SQL database.SQL injection attacks allow attackers to spoof identity, tamper with existing data, cause repudiation issues such as voiding transactions or changing balances, allow the complete disclosure of all data on the system, destroy the data or make it otherwise unavailable, and become administrators of the database server. [src: https://en.wikipedia.org/wiki/SQL_injection] |

| Unrestricted XXE / File System Access | CWE-611: External XML Entity Injection (XXE) is a specific type of Server Side Request Forgery(SSRF) which affects an XML processing engine server-side on a target. Specifically, blind XXE is when the results are either error-based or cause 3rd party interaction with services such as HTTP, FTP & DNS. An XXE attack typically occurs when XML input containing a reference to an external entity is processed by a weakly configured parser. An attacker can leverage an XXE attack to access sensitive data and read local or remote files. In a similar manner to SSRF, an attacker could introduce malicious code through Remote Code Execution (RCE). [scr: https://blog.zsec.uk/out-of-band-xxe-2/] [src: https://chris-young.net/2018/04/13/xxe-xml-external-entity/] |

| Significant Authentication Bypass | CWE-305: Authentication bypass is a vulnerability that allows an attacker access to credential protected resources without first acquiring valid credentials. Examples of this vulnerability include: SQL injection during login to bypasses credential authentication Direct access to resources normally beyond an authentication mechanism, such as a login screen, which do not independently validate the users authenticated session.* Failure to enumerate and enforce the systems' access policy. * A weak authentication system that allows a valid identity to be forged. |

| Significant Authorization Bypass | CWE-285: Authorization is the concept of allowing access to resources only to those permitted to use them. Vulnerabilities that bypass authorization checks may allow access to protected resources beyond what was intended by the system. Examples of authorization bypass include Insecure Direct Object Reference and Session Token Alteration. In each of these examples, the system trusts the users' requests because of improper or insecure implementation. |

| Cross Instance Privilege Escalation | Salesforce is a multi-tenant platform in which "instances" are created for each Org. A cross-instance privilege escalation involves some user in instance A having access to data in instance B without proper authorization. |

| Denial of Service | Susceptibility to an external, simply executed, single actor, logic-based attack resulting in a service outage or significant performance degradation of one or more critical systems/products |

| Disclosure of Personal Identifiable Information | CWE-200: Personally identifiable information, or PII, is any data that could potentially be used to identify a particular person. As it relates to Salesforce, PII Disclosure bugs involve PII data stored within any in-scope platforms, excluding Salesforce Employee data such as Name and Contact information. [src: https://www.lifelock.com/learn-identity-theft-resources-what-is-personally-identifiable-information.html] |

| Salesforce Platform Misconfiguration and/or Custom APEX Vulnerabilities (Salesforce Owned/Controlled) | The Salesforce Platform is highly configurable, customizable, and supports custom code in the form of APEX code, Visualforce pages, etc. It is therefore capable of being misconfigured in such a way as to leak information or to otherwise be insecure. This category of vulnerability is specific to Salesforce owned and operated sites, NOT Salesforce customer-owned and operated Salesforce instances. If you identify a configuration vulnerability in a customer site please report it to that company via their Bug Bounty program or their security@<some company dot com> email address. There is no guarantee that the customer will respond to your email or bug submission, and it is out of Salesforce control. Please do not expect Salesforce to handle reports of customer misconfiguration.|

| Privilege Escalation / Improper Access Control | Privilege escalation is the act of exploiting a bug, design flaw or configuration oversight in a software application to gain elevated access to resources that are normally protected from an application or user. The result is that a user with more privileges than intended by the application developer or system administrator can perform unauthorized actions. Note that Privilege Escalation is different from Permission Model Circumvention in that PE involves accessing functionality beyond that assigned to a given role, or somehow adding resource permissions to a given role without authorization, while PMC involves a complete bypass of security controls meant to enforce permissions. Ultimately, PE involves a user within the system increasing their access somehow, while PMC involves an anonymous user gaining access. [src: https://en.wikipedia.org/wiki/Privilege_escalation] |

| Non-XXE SSRF | In a Server-Side Request Forgery (SSRF) attack, the attacker can abuse functionality on the server to read or update internal resources. The attacker can supply or modify a URL which the code running on the server will read or submit data to, and by carefully selecting the URLs, the attacker may be able to read server configuration such as AWS metadata, connect to internal services like HTTP enabled databases or perform post requests towards internal services which are not intended to be exposed.[src:https://www.owasp.org/index.php/Server_Side_Request_Forgery] |

| Insecure Direct Object Reference | IDOR occurs when unvalidated user-supplied input is submitted and direct access to the object requested is provided. Vulnerability reports for IDOR are valid when the result is unauthorized information disclosure, modification or destruction of data, or performing a function outside of the limits of the current user. |

| CRLF injection/HTTP response splitting | HTTP response splitting occurs when data enters a web application through an untrusted source, most frequently an HTTP request. The data is included in an HTTP response header sent to a web user without being validated for malicious characters. HTTP response splitting is a means to an end, not an end in itself. At its root, the attack is straightforward: an attacker passes malicious data to a vulnerable application, and the application includes the data in an HTTP response header. [src: https://www.owasp.org/index.php/HTTP_Response_Splitting] |

| Circumvention of our Platform’s Permission Model | Permission Model Circumvention involves a complete bypass of security controls meant to enforce permissions. An example of PMC involves an insecurely configured system in which an API gateway fronts for several servers and implements authentication/authorization. The configuration is such that the URI to the backend servers can be identified and they are directly accessible without any additional authentication or authorization checks..While there is an authX model in place, it was trivially circumventable. Ultimately, PE involves a user within the system increasing their access somehow, while PMC involves an anonymous user gaining access. |

| Cross-Site Scripting (excluding self-XSS) | CWE-80: Cross-site scripting (XSS) is a type of computer security vulnerability typically found in web applications. XSS enables attackers to inject client-side scripts into web pages viewed by other users. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same-origin policy. [src:https://en.wikipedia.org/wiki/Cross-site_scripting] |

| Cross-Site Request Forgery (CSRF) on critical actions | CWE-352: Cross-site request forgery, also known as one-click attack or session riding and abbreviated as CSRF (sometimes pronounced sea-surf[1]) or XSRF, is a type of malicious exploit of a website where unauthorized commands are transmitted from a user that the web application trusts.[2] There are many ways in which a malicious website can transmit such commands; specially-crafted image tags, hidden forms, and JavaScript XMLHttpRequests, for example, can all work without the user's interaction or even knowledge. Unlike cross-site scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user's browser. [src: https://en.wikipedia.org/wiki/Cross-site_request_forgery] |

| Insufficiently Protected Credentials / Credential Exposure | CWE-522: CWE-522: Within the context of the Salesforce/HackerOne Bug Bounty program, credential exposure involves finding, or gaining access to a user or system credentials which are not meant to be public. An example of IPC would be finding a Github or other repo containing configuration files that contain usernames, passwords, API keys, private keys, etc. Another example is an exposure of a single user's credentials on the querystring, in cookies, or in other HTTP headers. |

| Insecure/Open Redirect | CWE-601: An HTTP parameter may contain a URL value and could cause the web application to redirect the request to the specified URL. By modifying the URL value to a malicious site, an attacker may successfully launch a phishing scam and steal user credentials. Because the server name in the modified link is identical to the original site, phishing attempts have a more trustworthy appearance. |

| DNS Hijacking / Subdomain Takeover | DNS hijacking or DNS redirection is the practice of subverting the resolution of Domain Name System (DNS) queries.The basic premise of a subdomain takeover is a host that points to a particular service not currently in use, which an adversary can use to serve content on the vulnerable subdomain by setting up an account on the third-party service. [src: https://en.wikipedia.org/wiki/DNS_hijacking] [src: https://www.hackerone.com/blog/Guide-Subdomain-Takeovers] |

| Configuration/Stats//Log File Exposure | CWE-532 Information Exposure Through Log Files. CWE-200: Information Exposure. Any instance in which log files or server/application configuration files are accessible when they are not meant to be. |

| Documentation Bug | Any instance in which, from a strictly security-based perspective, the published documentation is incorrect with regard to the behavior of the product. |

Non-Qualifying Vulnerabilities (Out of Scope)

The following types of issues are specifically excluded from our Bug Bounty Program:

Commerce Cloud Specific

• XSS that is stored in Business Manager and is reflected in the storefront / executed in a Storefront context.

• Admin to Admin or Admin to User XSS. In these cases, a higher privileged user is attempting to attack the lower privileged user. As an admin, such script execution is considered a feature due to the nature of the platform.

• CSRF in Storefront

• CSRF that can only be used to make modifications on the file system

• Session Fixation inside of Storefront

• XSS in the following areas: HTML Editor and file upload

• Login Page / Forgot Password Page Account Brute force or account lockout not enforced

• Submissions regarding product deficiencies, as opposed to exploitable vulnerabilities

Other Clouds and Services (Including Commerce Cloud)

• Access control to objects and fields in Salesforce are done through permission set or profile in setup tree. If that permission or profile in the setup tree is not respected, only then it is considered as an access control issue. Please check all permissions & profiles for that particular user before filling access control bugs.

• HTML and Link injections

• Issues related to "Editable Github Wiki Pages"

• Issues related to Salesforce Partner User Credential Disclosure in public code repositories such as GitHub. Please note that this type of activity is explicitly excluded by the Conduct Guidelines in this policy.

• TOCTOU bugs involving platform permission changes. For example; User A has an active session, Admin reduces or increases permissions for User A, User A permissions do not change until User A logs out and back in. This is currently WAD on Salesforce platforms.

• Invalid links from any Salesforce site to any social media site in which a claim of "account takeover" or "possible phishing attacks" are the basis for the report.

• Bugs in content/services that are not owned/operated by Salesforce

• Vulnerabilities affecting users of outdated or unsupported browsers or platforms

• Vulnerabilities that have already been addressed in a product update regardless of whether the update has been applied to the publicly available research machines

• Subdomain takeovers for out of scope domains

• Self-XSS or XSS bugs requiring an unlikely amount of user interaction

• XSS in our content sandbox under .content.force.com (http://content.force.com/)

• XSS under .sitepreview.(na\/gus).force.com (http://force.com/)

• XSS under .livepreview.(na\/gus).force.com (http://force.com/)

• XSS under .visual.force.com (with the exception of Salesforce developed and maintained apps like LiveMessage, Agile Accelerator, Private Appexchange, etc.)

• XSS in custom apps under .force.com (with the exception of lightning.force.com and Salesforce developed and maintained apps like LiveMessage, Agile Accelerator, Private Appexchange, etc.)

• Bugs categorized as P3 (low risk)

• SalesforceDX: Attacks by a root user against another user on the same machine

• SalesforceDX: Attacks by a user on the same user

• CSRF on forms that are available to anonymous users (e.g. web2lead contact form)

• Clickjacking and issues only exploitable through clickjacking

• Descriptive error messages (e.g. Stack Traces, application or server errors)

• HTTP 404 codes/pages or other HTTP non-200 codes/pages.

• Fingerprinting / banner disclosure on common/public services.

• Disclosure of known public files or directories, (e.g. robots.txt)

• Scripting or other automation and brute-forcing of intended functionality

• Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.

• Lack of Secure and HTTPOnly cookie flags

• Content spoofing (text injection) or IDN homograph attacks

• Tabnabbing

• Email configuration issues (SPF, DKIM, DMARC)

• Weak Captcha / Captcha Bypass

• Forced Login / Logout CSRF

• Account lockout, Login or Forgot Password page brute force

• Password complexity or account recovery policies

• Username / email enumeration (brute force)

• HTTPS Mixed Content

• Missing HTTP security headers, specifically: Strict-Transport-Security, X-Frame-Options, X-XSS-Protection, X-Content-Type-Options, and Content-Security-Policy.

• OPTIONS HTTP method enabled

• Known SSL issues (e.g. attacks such as BEAST, BREACH, POODLE, TLS Renegotiation)

• SSL Forward Secrecy or HSTS not enabled

• Weak SSL/TLS Cipher Suites

• CSV Excel Formula injection

• Issues related to networking protocols or industry standards not controlled by Salesforce

• Sending vulnerability reports using automated tools without validation

• Use of a known-vulnerable library without evidence of exploitability

• Problems related to widely publicized CVE's

• Attacks requiring physical access to a user's unlocked device

• Reports of spam, phishing or security best practices

• Reflected XSS involving Adobe Flash files (.swf)

If you are unsure whether a bug or issue that you discover in a participating service is a non-qualifying vulnerability, please email us at <bugbountymanager@salesforce.com>

Intellectual Property

Participating in the Bug Bounty Program does not grant to you or any other third party any rights to any Slack or Salesforce intellectual property, product or service. All rights not otherwise granted herein are expressly reserved. Whether or not we grant you a reward, you hereby assign to Salesforce all right, title and interest (including all intellectual property rights), in the contents of all vulnerability reports that you submit to Salesforce.

By participating in the Bug Bounty Program, you represent that you have the right to assign all such right, title and interest to us and that your participation in the Bug Bounty Program and assignment of such right, title and interest will not breach any agreement you may have with a third party (e.g. your employer).

Other Terms and Conditions

Salesforce pledges not to pursue a civil action or initiate a complaint to law enforcement against researchers for security research and vulnerability disclosure activities conducted in accordance with this Policy. We consider security research and vulnerability disclosure activities conducted in accordance with this Policy “authorized” conduct under the Computer Fraud and Abuse Act, the DMCA and applicable anti-hacking laws such as Cal. Penal Code 502(c). We waive any DMCA claim against you for circumventing the technological measures we have used to protect the applications in scope. If legal action is initiated by a third party against you and you have complied with this Policy, we will take steps to make it known that your actions were conducted in compliance with this Policy.

By participating in the Bug Bounty Program, you agree to be bound by these rules. These policies will apply to you in addition to, and will not replace, any other terms and conditions that are imposed by HackerOne.

• Your participation in the Bug Bounty Program does not create any kind of employment relationship or partnership between you and Salesforce. You must not hold yourself out as a Salesforce employee or as someone in any way affiliated with Salesforce.

• You must comply with all applicable laws in connection with your participation in this program.

• You are responsible for any applicable taxes associated with any reward you receive.

• Vulnerability reports received prior to the Bug Bounty Program launch are not eligible for rewards and may not be re-submitted for a reward.

• You will not use any of our trademarks, service marks and logos.

• We may modify this Policy at any time by posting an updated version of this document.

• We may terminate this Bug Bounty Program at any time without notice.