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 program 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 Australia data centers. 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 to ensure this happens on schedule and inform Cloudsmith staff of potential issues.
We secure access to the Cloudsmith by firewalls and VPNs and utilize bi-directional encrypted communication internally and externally. There are no external routes into the Cloudsmith infrastructure, and admission is granular and requires multiple authentication factors.
Your sensitive information, including (but not limited to) your password and secret answers, are stored as one-way cryptographic hashes using industry-grade ciphers. This is reviewed on minor website releases 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 are authenticated only by using your correct sign-in ID, password, and API token. It would be best if you kept your password and API token confidential and did not share it with anyone else. You are responsible for using the Services by any other person using your sign-in credentials. Two-factor authentication (2FA) is also available and recommended, and you can enforce this within your organization.
Application code is peer-reviewed and vetted for issues. 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 exploits.
Cloudsmith has been verified as secure by third-party pen-testing against the OWASP ASVS 4.0 standard, and we also utilize automated penetration services to test the frontend applications for known attack vectors continually. We log any issues which are remediated based on severity and impact.
Finally, we are ISO 27001 compliant, and therefore model our security practices after attaining compliance.
Only authenticated and authorized 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 to assist with support tickets, enabling them to view the frontend website as your user.
We built Cloudsmith 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 have influenced every aspect of design from each node to overall architecture.
We host Cloudsmith across multiple data centers, regions, and availability zones, with redundancy built in at each service layer and platform layer. 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 architect to avoid Single Point(s) of Failure (SPOF) for 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). All data (internal and customer state) is also stored and versioned redundantly.
In the case of important information, such as your packages, we store multiple files and data versions for redundancy and security reasons. We don't typically offer a restore service for purposefully deleted packages and data. Still, we may consider it on request and potentially for a fee, depending on the scope of recovery.
Rolling windows are used to backup critical information such as relational databases, transit, messaging queues, application caches, system images, etc. The thought of losing any data goes against our principles and goes against our primary reason for being 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 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.
For security incidents that occur, Cloudsmith follows a defined incident response. The following is a summarised version of the official incident response procedures utilized by Cloudsmith:
Investigation: The team either receives a report of any 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 an infrastructure breach, the response will proceed to Escalation. Otherwise, a ticket is raised and handled outside of incident response.
Escalation: The issue is escalated from the team's investigatory member to the other team members responsible for security, including the security lead. The team self-mobilizes into two sub-teams; one for mitigation and another for remediation; both reporting to the security lead, who assumes the role of the incident commander. The response moves to a simultaneous phase of Mitigation, Notification, and Remediation.
Mitigation: The mitigation team moves to prevent further damage (e.g., shutting down services, blocking at the WAF, etc.) and monitors the system to assess impact. If possible, the issue is stopped at the source and minimized. 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, which impacts users, then the notification may be site-wide. Suppose the urgency is high, and it is known that customers are directly affected. In that case, the incident commander may choose to communicate with the customers immediately at this stage, with a known level of detail. Otherwise, notification is left until Closure.
Remediation: The remediation team investigates the root cause for the security incident (e.g., an exploit allowing remote-code execution) and works 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, the 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 whole team for this stage. The incident commander works with the comms officer to finalize notifications for impacted users, plus details of what occurred and why. The final step, 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 analyzed again, including the timeline from the exploit to the RCA and the fix. The team discusses and agrees on actions (if necessary), 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 6 months ago