How We Enhance Security at CloudBees CodeShip

Intro

The CodeShip team has always been security minded, but ever since joining CloudBees a little over a year ago we’ve had more resources than ever to help put our security - which means our user’s security - front and center.

Recently, we did an extensive audit looking for small security issues - and, with a little help from HackerOne, we found some. It was an interesting first few days of testing - we learned, for instance, that you should always give your on call team plenty of heads up when you’re about to incentivize people to challenge your infrastructure. A few calming conversations and inadvertent pages later, we were pretty excited to start finding out all the things we could improve on.

Some of these things we knew about and just needed to better isolate the priority of them, and others were a surprise to us due to the creativity involved. We want to be open about these types of things, because all web applications have security problems and weird corner cases, and we’re no different - we’re just glad to keep better and to keep learning more.

Changes made

I won’t inventory every change made - that might be a security risk, after all. But, I do want to touch on a few of the interesting, small things we’ve fixed, if nothing else because you learn a lot about your product from the ways in which it can be misused.

• We had never capped the number of notification rules that could be created via our API. This turned out to be a fun opportunity for someone to create a CloudBees CodeShip account, easily create tens of thousands of webhook notifiers and use our system to attack someone else. Our notification queues also did not love this. Fixed!

• Password resets were old functionality for us, while two-factor auth was new functionality. When we added two-factor auth, we didn’t consider that we should also require the additional security check when doing password resets. We added 2FA to password reset screens now.. Turns out, we were allowing password resets to override two factor. It didn’t let someone sign it, but it did let a password get changed without requiring two-factor authentication. Not great. Fixed!

• We’ve improved encryption and key rotation systems for pieces of our AWS infrastructure, with new company-wide oversight in place. There’s arguably nothing more critical for us to keep secure, so we love the added scrutiny and support here.

Going forward

Like I said, these aren’t the only changes we’ve made - we’ve resolved quite a few tickets on issues big and large, some standard and some quite odd. This will continue to be part of our work and part of our focus more than ever going forward. There were pros and cons to being an independent small company like CodeShip was and now rapidly growing as a part of CloudBees today, but without a doubt one pro is the level of effort and time you can put into security once you have more people and dedicated teams. As I said earlier, we’ve always cared and tried our hardest, but now we can do more than ever to meet our standards.

Additional resources

• Read more about how SaaS CI/CD solutions work for open source projects

• Learn more about CloudBees CodeShip unified build page

• How visual testing is integrated into the CloudBees CodeShip workflow