Security Policy

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.

System Security

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.

Application Security

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.

Employee Access

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.

High Availability/Redundancy

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 failover-oriented redundancy at each service and platform layer. Where possible, we leverage elastic load balancing (such as Amazon ELB) and layers of nodes that automatically scale as service demand 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. All data is written to high-availability storage (such as Amazon S3) or passes through fault-tolerant and reliable messaging services (such as RabbitMQ). S3 is designed to provide 99.999999999% durability and 99.99% availability.

In the event of a catastrophic incident within the data infrastructure, such as database corruption, DDoS or other system failure (all of which have risk mitigation capabilities), Cloudsmith provides an RPO and RTO of 24 hours. Depending on the circumstance of a catastrophic event, a recovery point of less than ten minutes is possible.

Backup Policies

For important information, such as your packages, we store multiple files and data versions for redundancy and security reasons. Packages that were intentionally deleted by customers are soft-deleted and can be restored for up to two weeks.

Rolling windows are used to backup critical information such as relational databases, transit, messaging queues, application caches, system images, etc. The thought of losing data goes against our principles and our primary reason for being a first-class package management service, so we take all possible measures 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.

Incident Response

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:

1. 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.

2. 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.

   1. 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.

   2. 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.

   3. 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.

3. 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.

4. 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.