Bug Bounty Program

Overview

Cloudsmith aims to keep its Service safe, and data security is of utmost priority. Suppose you are a security researcher and have discovered a security vulnerability in the Service. In that case, we appreciate your help disclosing it privately and allowing us to fix it before publishing technical details.

Cloudsmith will engage with security researchers when vulnerabilities are reported to us, as described here. We will validate, respond to, and fix vulnerabilities to support our commitment to security and privacy. We won't take legal action against, suspend, or terminate access to the Service of those who responsibly discover and report security vulnerabilities. Cloudsmith reserves all of its legal rights in the event of any noncompliance.

We are pleased to offer thanks or a bounty reward for vulnerability information that helps us protect our customers. Thanks to the security researchers who chose to participate in our bug bounty program. This will range from the public thanks to a variable monetary amount or loot (depending on our budget and the impact).

Rules & Process

Suppose you identify a verified security vulnerability in compliance with this Security Disclosure Policy (i.e., Bug Bounty Program). In that case, you can submit this to our bug bounty program with the following process:

1. You should determine if an exploit is viable (i.e., practically possible).
2. You should also check to ensure it's not explicitly out-of-scope (see below).
3. You can report the exploit to us using the relevant information (see below).
4. We will acknowledge receipt of the disclosure and triage impact and then schedule a review.
5. The urgency for review will be determined based on the type and impact of the exploit.
6. It may take up to one month to triage, depending on how busy the team is.
7. Timeframes are typically hours for critical/high, days for medium and (up to) weeks for low.
8. Please do NOT send continual "any update?" messages; we get reminded automatically.
9. We will let you know if the exploit is viable and whether we accept it as a bug bounty (or not).
10. If viable and fixed, we will publicly thank you on our Hall of Fame.
11. You may also be issued with an award in addition to being placed in the Hall of Fame.

❗️

Unauthorised Cross-Account Access

Please note that in absolutely no event are you permitted to access, download or modify data residing in any other Account, or one that is not registered to you; unless permission is expressly provided by the Account Owner.

🚧

Monetary Award Tax

If a monetary award is provided as a bounty then you are responsible for paying any taxes associated with the reward. We are obliged by law to report any such awards to the tax authorities, so please ensure that you handle this appropriately.

In Scope

The bug bounty scope applies to the Cloudsmith Service, the Cloudsmith Service API, and the Cloudsmith Site.

The vulnerability classifications that are considered in-scope are:

• Access Control Bypass;
• API Misuse Issues;
• Authentication (Broken or Bypassed);
• Business Logic Issues;
• Cross-Site Scripting (XSS);
• Cross-Site Request Forgery (CSRF);
• Complexity Bomb;
• Decompression Bomb;
• Directory Traversal;
• Improper TLS protection;
• Open URL Redirection;
• Privilege Escalation;
• Provisioning Errors;
• Remote Code Execution (RCE);
• Sensitive/Private Data Leaks;
• Session Fixation;
• Session Management (Broken or Bypassed);
• Subdomain/Domain Takeover;
• SQL Injection.

It might be applicable if a vulnerability isn't explicitly listed here as in-scope or in the next section as out-of-scope. Still, we reserve the right to determine this in communication with the security researcher.

Out Of Scope

Application bugs that are explicitly NOT considered to be in-scope:

• Any standard (i.e., non-security) application or API bugs (e.g., display issues, ordering issues, search issues, input/output issues, etc.), unless they involve privilege escalation or cross-account access.
• Any UI-based injection or non-critical security bugs for the duration of our UI replacement project (we're currently rebuilding the UI as a separate experience; therefore, any bugs that impact our current UI will not qualify).

Actions/areas that are explicitly NOT considered to be in-scope:

• Executing or attempting to execute any Denial of Service (DoS) attack.
• Knowingly posting, transmitting, uploading, linking to, sending, or storing any Malicious Software.
• Attempting to social engineer support or other staff.
• Testing in a manner that would result in the sending of unsolicited or unauthorized junk mail, spam, pyramid schemes, or other forms of duplicative or unsolicited messages.
• Testing in a manner that would degrade the operation of the Service.
• Testing or otherwise accessing or using the Service from any Prohibited Jurisdiction.
• Testing third-party applications, websites, or services that integrate with or link to the Service.

Vulnerabilities that are explicitly NOT considered to be in-scope:

• Clickjacking, CSRF, and content spoofing issues without demonstrable security impact.
• Publicly known vulnerable libraries without a working Proof of Concept.
• Self-XSS or having a user paste JavaScript into the browser console.
• Issues relating to non-Cloudsmith products.
• Open ports scanning, banner grabbing, and software version disclosure issues.
• Issues that affect only outdated user agents or unsupported platforms.

Non-qualifying best practices that are explicitly NOT considered to be in-scope:

• Missing cookie flags on non-authentication cookies.
• Missing best practices in DNS configuration (e.g., DKIM/DMARC/SPF/TXT).
• Missing best practices in SSL/TLS configuration.
• Missing best practices in Content Security Policy (CSP) or lack of other security-related headers.
• Leakage of sensitive tokens (e.g., reset password token) to trusted third parties via HTTPS.
• Ability to utilize the same token (e.g., reset password token) within a very short period.

Non-qualifying business practices that are explicitly NOT considered to be in-scope:

• Institution access code enumeration or demonstrating access codes leaked in internet forums.
• Credential re-usage from public dumps.
• UUID enumeration of any kind.
• Ability to determine if a username or email has a Cloudsmith account.
• Signing up with multiple accounts to abuse referral code usage.
• Password length, complexity, and re-use requirements.
• Email verification workflow.

Websites/services that are explicitly NOT considered to be in-scope:

• Help Website (https://help.cloudsmith.io) - this is hosted by https://readme.io.
• Blog Website (https://blog.cloudsmith.io) - this is hosted by https://ghost.io.
• Status Website (https://status.cloudsmith.io) - this is hosted by https://statuspage.io.
• Changelog Website (https://changelog.cloudsmith.io) - this is hosted by https://getbeamer.com.
• Amazon Web Services (https://aws.amazon.com/) - this is our infrastructure provider.
• Cloudsmith staging and development environments - only production systems are in-scope for the bug bounty program.
• Any third-party widgets, such as:
  • Chat widget (powered by Intercom).
  • Changelog widget (powered by Beamer).
  • Status widget (powered by Statuspage).
• Any websites under the following domains:
  • *.readme.io (incl. dash.readme.io and cloudsmith.readme.io)
  • *.googleapis.com
  • *.googletagmanager.com
  • *.google-analytics.com
  • *.doubleclick.net
  • *.hubspot.com
  • *.bing.com
  • *.fullstory.com
  • *.hotjar.com
  • *.statuspage.io
  • *.getbeamer.com

Severity

When we issue bug bounties, we assign them a severity level. This represents the level at which we assess the impact of the disclosed security issue, and it influences the bug bounty award. Please remember that any decisions regarding assessed severity and impact are final, and we reserve the right to determine them.

Severity Level: CRITICAL

Vulnerabilities that score in the critical range usually have most of the following characteristics:

• Exploitation of the vulnerability likely results in root-level compromise of servers or infrastructure devices.
• Exploitation is usually straightforward. The attacker does not need exceptional authentication credentials or knowledge about individual victims and does not need to persuade a target user, for example, via social engineering, to perform any special functions.

Severity Level: HIGH

Vulnerabilities that score in the high range usually have some of the following characteristics:

• The vulnerability is difficult to exploit.
• Exploitation could result in elevated privileges.
• Exploitation could result in significant data loss or downtime.

Severity Level: MEDIUM

Vulnerabilities that score in the medium range usually have some of the following characteristics:

• Vulnerabilities that require the attacker to manipulate individual victims via social engineering tactics.
• Denial of service vulnerabilities that are difficult to set up.
• Vulnerabilities where exploitation provides only minimal access.
• Vulnerabilities that require user privileges for successful exploitation.

Severity Level: LOW

• Vulnerabilities in the low range typically have little impact on an organization's business.

Timeliness

We endeavor to try and fix security bugs within the following timelines:

Reporting

To start the reporting process, please share the details of any suspected vulnerabilities with the Cloudsmith Security Team by sending us the details to [email protected]. Please do not publicly disclose these details outside this process without explicit permission.

In reporting any suspected vulnerabilities, please include the following information:

• Vulnerable URL: The URL where the vulnerability occurs;
• Vulnerable Parameter: If applicable, the parameter where the vulnerability occurs;
• Vulnerability Type: The type of vulnerability;
• Steps to Reproduce: Step-by-step information on how to reproduce the issue;
• Screenshots: A demonstration of the attack to aid description and
• Attack Scenario: An example attack scenario may help demonstrate the risk and resolve your issue faster.

Reserved Rights

Cloudsmith reserves all rights to decide on scope, impact, and reward.

If another researcher has previously reported an exploit, only the first disclosure will be considered. However, you'll always have our appreciation, and we'll let you know if this happens. This often occurs due to the number of submissions that we get.

If we cannot replicate the issue, regardless of the timeframe between the report and our triage, we cannot award any bounties. We'll try our best to replicate this, but please know that we don't receive reports, so we fix them without acknowledgment.

Finally, regardless of the reason, we do not tolerate abuse or threats to our staff or company. We reserve the right to terminate and block all communication with such people. Everyone should acknowledge and respect that there is a Human being on both sides of every communication.

Acknowledgement

Thank you for helping us make the package management world a bit safer. 💯