Effective Date: July 9, 2020
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 incredibly particular about how we handle sensitive data, and we know that the security of Cloud-based services is paramount to their reputation. For security researchers, we have a bug bounty programme as described towards the bottom of this document.
Cloudsmith is hosted securely by Amazon Web Services within Virtual Private Clouds (VPCs) within the Europe West, US East Coast, US West Coast and Sydney Australia, data centres. Cloud Security is taken extremely seriously by both Amazon and Cloudsmith. Please review Amazon's Cloud Security Protocols for more information.
We apply security-critical system patches to machines within a daily maintenance window and non-critical patches within a weekly maintenance window. The process is automated ensure that this happens on schedule, and to inform Cloudsmith staff of potential issues.
We secure access to the Cloudsmith by firewalls and VPNs and utilisesbi-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.
Any of your sensitive information including (but not limited to) your password and secret answers are stored as one-way cryptographic hashes using a industry-grade ciphers, 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 API token. You must keep your password and API token confidential and not share it with 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 you can enforce this within your organization.
Application code is peer-reviewed and vetted for issues, and several layers of defence exist to combat issues such as Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF), SQL Injection, Session Hijacking, and other forms of exploits.
Cloudsmith has been verified as secure by third-party pen-testing, against the OWASP ASVS 4.0 standard, and we also utilise automated penetration services to continually test the frontend applications for known attack vectors, and we log any issues, which are remediated based on severity and impact.
Finally, we're in the planning process of applying for ISO27001 compliance, and therefore model our security practices after attaining compliance.
Only authenticated and authorised employees of Cloudsmith Ltd are allowed access to the Cloudsmith infrastructure. We log all interactions with the infrastructure 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; but this is infrequent. Employees may also "switch into" your account for assisting with support tickets - this enables them to view the frontend website as your user.
We built Cloudsmith has to harness the potential of the Cloud, as it says in the name of the service, platform and company. High availability and redundancy have been a formative and primary concern since conception and influences every aspect of design from each node up to overall architecture.
We host Cloudsmith across multiple data centres 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.
We avoid single point-of-failure (SPOF) nodes and services and all data is written to high availability storage (such as Amazon S3) or passes through fault-tolerant and reliable messaging services (such as RabbitMQ).
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 data but we 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 goes against our principles and goes against our primary reason for being as a first-class package management service, so we take all measures possible to avoid it.
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.
See the Bug Bounty Programme for details on bug bounties.
For security incidents that occur, Cloudsmith follows a defined incident response. The following is a summarised version of the official incident response procedures utilised by Cloudsmith:
Investigation: The team either receives a report of unusual or suspicious activity, or discovers it via active monitoring, and investigates whether it is an issue, and if so, what level of severity and impact. If an issue is confirmed, has the potential to impact customers and/or involves a breach of the infrastructure, then the response will proceed to Escalation. Otherwise, a ticket is raised and is handled outside of incident response.
Escalation: The issue is escalated from the investigatory member of the team to the other members of the team responsible for security, including the security lead. The team self-mobilises into two sub-teams; one for mitigation, and another for remediation; both reporting to the security lead, who assumes the role of incident commander. The response moves to a simultaneous phase of Mitigation, Notification and Remediation.
Mitigation: The mitigation team moves to prevent any further damage (e.g. shutting down services, blocking at the WAF, etc.), and also monitors the system to assess impact. The issue is stopped at the source, if possible, and is otherwise minimised. The incident commander is informed of progress every 15 minutes. The analysis from the mitigation team is used for the root cause analysis, and to determine which specific customers may be impacted.
Notification: The incident commander works with a comms officer to notify affected parties if known at this stage. If the mitigation involves stopping services, and this has an impact on users, then the notification may be site-wide. If the urgency is high, and it is known that customers are directly impacted, then the incident commander may choose to communicate with the customers immediately at this stage, with a level of detail that is known. Otherwise, notification is left until Closure.
Remediation: The remediation team investigate the root cause for the security incident (e.g. an exploit allowing remote-code execution), and work on a permanent fix. The incident commander is informed of progress every 15 minutes, including an estimated time-to-fix. The goal is to remediate the issue before any further mitigation is necessary. When complete, response proceeds to Closure.
Closure: Once the incident is confirmed to be mitigated and remediated, the final stages of the incident response are to measure the actual level of impact and who was impacted by it. The sub-teams rejoin as a full team for this stage. The incident commander works with the comms officer to finalise notification for impacted users, plus details of what occurred and why. The final stage, conducted at a near-term future date is to consider how it could be prevented via the Retrospective, but at this stage, the actual incident response is closed.
Retrospective: At a later point, the incident is analysed again, including the timeline from the exploit through to the RCA and the fix. The team discusses and agrees on actions (if necessary), as to why it had occurred, what went well (or not well), and how it could be improved next time. Depending on the severity and the impact of the incident, this may also be published as a follow-up to the previous notifications.
Updated 4 months ago