Welcome back. In this series (based on my Summit 2019 talk), I’ve been talking about the process we went through to turn Atlassian’s 3600-audit tests into a single test while also increasing our compliance. You can see the past two portions of the series here:
Today, I’d like to continue by talking about where our compliance process landed and the results of that change.
When the planning stages were over, we implemented a new process that focused heavily on peer reviews and automated compliance checks to meet our own significant compliance obligations as a public company operating worldwide, include SOX, PCI, SOC, and GDPR.
Here’s the process that keeps us compliant:
All Atlassian code is stored in BitBucket. When a developer wants to make a change, they check the code out of BitBucket and onto their laptop. When they check it back into the BitBucket repository, instead of updating the code, the system is set up to require peer review. Only after that review is done and approved is the code pulled back into the repository.
And if the code isn’t approved? It gets sent back to the original developer with the peer reviewer’s notes. They fix what’s wrong and submit it for another peer review.
This process is automated and it’s an out-of-the-box feature of BitBucket, so any team can take advantage of it as soon as they start using the software.
Most compliance processes involve a compliance board. At Atlassian, we vetoed that option—and hard. Because the truth is that most boards don’t have the in-depth knowledge of code that the developers do. And how can you vet code if you don’t understand it?
Setting up a peer review process where developers who understand the code are checking each other’s work simply made more sense both in terms of compliance and agility.
Once the code in BitBucket is ready, we use Bamboo to build, test, and deploy. Bamboo is set up to check if compliance settings are turned on in BitBucket. If so, it starts the build. If not, it stops in its tracks.
This means that if someone turns off compliance in BitBucket, Bamboo will never push our non-compliant code into a build.
When Bamboo does the build, it builds the service that’s going to run in production and cryptographically signs that service to confirm that it has come from the right environment.
And if someone changes it? It loses the signature.
Because our production environment only runs signed artifacts, this ensures that nobody can shortcut the process and skip the compliance measures. If it’s not signed, it won’t run. Period.
If you know Atlassian, you also know that we’re committed to being a Cloud-first business. Because the Cloud sets you free from maintenance hassles, frees you up to focus on your customers, and lowers costs so that mid-sized businesses can compete with large organizations.
So, how does the Cloud do with complex compliance processes? The answer is that we’re on the Cloud, so all of the above faster, better compliance process is done on the Cloud. That’s how much we trust the privacy and security we’ve built into our Cloud products.
What did this all these process changes mean for Atlassian’s speed and compliance?
Watch for the final piece in this series for a breakdown of our results.
Now, to you: What does your compliance process look like? Have you gone through a similar shift (or in a completely different direction)? What were the results?
Hello Compliance fans! I wanted to jump in this group to introduce a brand new Community group that our Atlassian Security team started. The Trust and Security group is a space to share inform...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events