Hey! These docs are for version 1.0, which is no longer officially supported. Click here for the latest version, 1.2!

Security Policy

Effective Date: August 20, 2019

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/TLS. 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 (2FA) is also available, recommended, and can be enforced within organizations.

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 and data for redundancy and security reasons. We don't normally offer a restore service for purposefully deleted packages and/or data 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, and goes against our primary reason for being as a first-class package management service, so we take all measures possible to avoid it.

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)

See the Bug Bounty Programme for details on bug bounties.

Did this page help you?