The Cloudsmith Developer Hub

Welcome to the Cloudsmith developer hub. You'll find comprehensive guides and documentation to help you start working with Cloudsmith as quickly as possible, as well as support if you get stuck. Let's jump right in!

Get Started    

Security Policy

Effective Date: January 10, 2018

At Cloudsmith we strive to implement extensive and reasonable measures to prevent unauthorized access, modification, destruction, or damage of your personal information and data stored using the Services. We're extremely particular about how sensitive information is handled, and we know that the security of Cloud-based services is paramount to their reputation. Please be reassured that security is a top concern for us! For security researchers, we have a bug bounty programme as described towards the bottom of this document.

System Security

Cloudsmith is hosted securely by Amazon Web Services within Virtual Private Clouds (VPCs) within the Europe West (eu-west) and US East Coast (us-east) data centers. Cloud Security is taken extremely seriously by both Amazon and Cloudsmith. Please review Amazon's Cloud Security Protocols for more information.

Security-critical system patches are applied to machines within a daily maintenance window and non-critical patches are applied within a weekly maintenance window. Automation is in process to ensure that this happens and to ensure that Cloudsmith staff are informed of potential issues.

Access to the Cloudsmith is secured by firewalls and VPNs and utilises bi-directional encrypted communication, both internally and externally. There are no external routes into the Cloudsmith infrastructure and access is both granular and requires multiple factors of authentication.

Application Security

Any of your sensitive information including (but not limited to) your password and secret answers are stored as one-way cryptographic hashes using an extremely strong algorithm (and this is reviewed on minor releases of the website to ensure the highest level of protection).

All private data exchanged publicly with Cloudsmith is always transmitted over industry-standard 256-bit encrypted SSL. All communication and data internally is encrypted end-to-end, both in-transit and at-rest. Encryption of storage is a combination of AES256 and AWS KMS.

Your account, information, data, and access to the Services is authenticated only by the use of your correct sign-in ID, password, and/or API token. You must keep your password and API token confidential and not share it to any other person. You are responsible for the use of the Services by any other person using your sign-in credentials. Two-factor authentication is on the Cloudsmith Development Roadmap.

Application code is peer-reviewed and vetted for issues, and several layers of defense exist to combat issues such as Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF), SQL Injection, Session Hijacking, and other forms of exploits.

Finally, we utilise automated penetration services to continually test the frontend applications for known attack vectors, and any issues are logged and rectified based on severity. We also have plans to conduct 3rd party penentration testing of internal networks in the future, but we're confident that our security practices would meet a high grade.

Employee Access

Only authenticated and authorised employees of Cloudsmith Ltd are allowed access to the Cloudsmith infrastructure. All interactions with the infrastructure are logged and employees must have specific and justifiable reasons for connecting.

All access is encrypted and must be done so through pre-defined secure channels.

With your permission (unless for anti-fraud or security-related reasons) employees may access your private information, including the contents of any private repositories. Employees may also "switch into" your account for providing assistance on support tickets - this enables them to view the frontend website as your user.

High Availability/Redundancy

Cloudsmith has been designed to exploit the potential of the Cloud, as it says in the name of the service, platform and company. High availability and redundancy has been a formative and primary concern since conception and influences every aspect of design from each node all the way up to overall architecture (watch out for a series of blog posts on this!)

We are hosted across multiple data centers and multiple regions, with redundancy built-in at each layer of the service and platform. Where possible we leverage elastic load balancing (such as Amazon ELB) and layers of nodes that automatically scale as the demand for service increases. Nodes that fail are automatically replaced with a new instance.

Single point-of-failure nodes and services are avoided and all data is written to highly availability storage (such as Amazon S3) or passes through fault-tolerant and reliable messaging services (such as RabbitMQ).

Backup Policies

In the case of important information, such as your packages, we also store multiple versions of files for redundancy and security reasons. We don't normally offer a restore service for deleted packages but may consider it on request and potentially for a fee depending on the scope of recovery.

Rolling windows are used for backup of critical information such as relational databases, transit and messaging queues, application caches, system images, etc. The thought of losing any data at all sounds painful to us, so we'd really like to avoid it if possible!

Credit Card Processing

When you sign up for a paid account on Cloudsmith, we do not store any of your critical card information on our servers (such as the full card number or the CVC). Your credit card information is processed securely by our payment processor, Stripe.

Responsible Disclosure Policy (Bug Bounty Programme)


Cloudsmith aims to keep its Service safe for everyone, and data security is of utmost priority. If you are a security researcher and have discovered a security vulnerability in the Service, we appreciate your help in disclosing it to us privately and giving us an opportunity 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, and fix vulnerabilities in support of our commitment to security and privacy. We won’t take legal action against, suspend, or terminate access to the Service of those who discover and report security vulnerabilities responsibly. Cloudsmith reserves all of its legal rights in the event of any noncompliance.

If you identify a verified security vulnerability in compliance with this Security Disclosure Policy, Cloudsmith commits to:

  • Acknowledge receipt of your vulnerability report in a timely manner;
  • Notify you when the vulnerability is fixed; and
  • Publicly thank you for your responsible disclosure and helping us safe.

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.

Bug Bounties / Hall of Fame

We are pleased to offer thanks and/or a bounty reward for vulnerability information that helps us protect our customers as a thanks to the security researchers who choose to participate in our bug bounty program. This will range from public thanks to a small monetary amount or loot of some sort (depending on our budget). Cloudsmith will decide the bounty reward at our sole discretion, and all decisions are final.


  • Upon acknowledgement of a viable exploit we will discuss the options with the reporter.
  • We will add the reporter's name/link to the Hall of Fame alongside exploit details.
  • If a bounty was determined this will be issued on resolution exploit resolution.

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 and the Cloudsmith Service API.

The vulnerability classifications that are considered in-scope are:

  • Access Control Bypass;
  • API Misuse Issues;
  • Business Logic Issues;
  • Broken Authentication;
  • Broken Session Management;
  • 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;
  • Subdomain/Domain Takeover;
  • SQL Injection.

If a vulnerability isn't explicitly listed here as either in-scope and isn't explicitly mentioned in the next section as out-of-scope then it might be applicable, but we reserve the right to determine this in communication with the security researcher.

Out Of Scope

The following actions/areas are not considered to be in-scope:

  • Executing or attempting to execute any Denial of Service (DoS) attack; or
  • Knowingly posting, transmitting, uploading, linking to, sending or storing any Malicious Software; or
  • Attempting to social engineer support staff; or
  • 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; or
  • Testing in a manner that would degrade the operation of the Service; or
  • Testing or otherwise accessing or using the Service from any jurisdiction that is a Prohibited Jurisdiction; or
  • Testing third party applications or websites or services that integrate with or link to the Service.

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


In order to start the reporting process, please share the details of any suspected vulnerabilities with the Cloudsmith Security Team by sending us the details to Please do not publicly disclose these details outside of 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 the vulnerability;
  • Steps to Reproduce: Step-by-step information on how to reproduce the issue;
  • Screenshots or Video: A demonstration of the attack; and
  • Attack Scenario: An example attack scenario may help demonstrate the risk and get your issue resolved faster.

Security Policy