If you've been following along at any of our developer events, in the blog, or on the developer community in the past year, you'll know that cloud app trust has been an important topic here at Atlassian.
As more customers—and especially large customers—move to cloud, we are hearing increased requests for more information about what apps are doing with customer data in cloud. Data protection is a key concern for customers, many of whom are operating in regulated environments. Customers vet and approve Atlassian's cloud products (see our trust center for details on our approach to meeting customer needs), and expect the apps that extend those products to handle their data with the same care.
It's important to keep these customer needs in mind when investing in existing apps and app businesses, but it's equally important to think about data protection when building from the ground up.
The decisions you make about how an app stores and processes data can save you time and money, and help you attract more trust-conscious customers down the road.
What do we mean by "secure by design"?
According to the US Cybersecurity and Infrastructure Security Agency, secure by design projects are:
those where the security of the customers is a core business requirement, not just a technical feature. Secure by Design principles should be implemented during the design phase of a product's development lifecycle to dramatically reduce the number of exploitable flaws before they are introduced to the market for broad use or consumption.
In practice, designing products with security in mind can involve anticipating and minimizing opportunities for attack, ensuring your product's default and failure states are secure, and setting up operations to reduce opportunities for exploitation or fraud. The Open Worldwide Application Security Project (OWASP) lists the following secure by design principles for SaaS businesses:
- The principle of least privilege and separation of duties
- Least privilege: Users should only be given the minimum amount of access necessary to perform their job.
- Separation of duties: No single individual should have complete control over every aspect of a transaction.
- The principle of defense-in-depth: Multiple layers of security should be incorporated in so that if one layer fails, the other layers will still be able to protect the asset (customer data, for instance).
- The principle of zero-trust: Organizations should always assume that all users, devices, and networks are not trustworthy and must be authenticated before allowing access.
- The principle of secure-in-the-open: Developers should be aware of the security implications of their code and take steps to ensure that their code is secure. This includes using secure coding practices, testing for vulnerabilities, using secure development tools, and consulting with security experts when needed.
All of these principles (which you can read more about here) should be followed to help you build security into the foundations of your app or product.
When we talk about secure by design principles for Marketplace apps, we mean these overarching principles, but we have a few additions. This is because your technical landscape is woven into ours, and because our customers are shared. They've often already vetted Atlassian's products and practices, and want trust features to extend to Marketplace apps.
Secure by design for Marketplace Apps
In addition to the foundational principles of secure by design, we urge developers to consider the following principles to benefit from Atlassian's investments in security, but also in other important elements of data protection and management:
Build with Atlassian's Cloud App Security Requirements in mind
Regardless of where your app is hosted, you must also build with security best practices in mind. Atlassian's security requirements are focused on:
- Authentication and authorization of every request on all endpoints exposed
- Data protection, including TLS encryption and securely storing secrets
- Application security, including securely configuring domains, enabling security headers, sanitizing untrusted data, not using libraries with vulnerabilities and more
- Vulnerability management, involving engagement with Atlassian's security team and vulnerability management programs
You can review the full list of security requirements for cloud apps here. We also open source several of our security scanners so that you can check your own apps for missing security requirements. You can find more information about scanning and our security requirement testing tools for developers here on the developer portal.
Least privileged access
Least privileged access is a core principle of secure product design for any product. When building an app for the Atlassian Marketplace, you should use available scopes to minimize what your app can see and interact with whenever possible. Only request scopes required for the app to perform its intended functionality and nothing more.
In addition to building your app in a way that minimizes access to customer data, we're working to build controls that give customers more say when it comes to what data apps can access in their environment.
Least data egress
In short, developers should minimize the need for data to leave the parent product whenever possible. This is particularly true for sensitive data or personal data.
In the Privacy & Security tab, you have space to explain what End User Data your app stores or processes, and space to share any 3rd party locations where your app processes End User Data. This is because customers often want to know exactly where their data is going and who is handling it so they can make sure it's not falling into untrustworthy hands.
The more things stay within Atlassian, the easier it is for customers to assess and trust your app.
Use Atlassian's infrastructure
Along the same lines as least data egress, we recommend that, whenever possible, developers use Atlassian's infrastructure for data storage and processing.
Atlassian is responsible for our own infrastructure, and we invest heavily in ensuring this infrastructure is secure and built to protect customer data from loss or attack. (You can read a detailed explanation of our approach to data protection here).
By the time they're using our cloud products, most customers have already vetted and decided to trust Atlassian’s infrastructure and our company's operational processes.
If an app stores End User Data outside of Atlassian's infrastructure (or even processes data outside of Atlassian in some cases), customers must independently trust that app and the company behind it to ensure their data is handled securely. What's more, the app's developer must independently ensure the app's infrastructure supports all the things customers need to trust your app, like data residency, data security, and compliance with relevant frameworks and regulations.
Using Atlassian's infrastructure makes it easier for you to manage your apps, as we'll take care of a lot of the heavy lifting.
What are some ways to build a "secure by design" app?
Building an app with security in mind starts, as you might guess, during the solution design stage of your app development journey. Security, compliance, and data protection in general should play a role in how you think about your app's architecture and infrastructure, and in how you operate as a company with respect to customer data.
In practice, when building an app for the Atlassian Marketplace, this can look like:
- Deciding to build an app that only uses Forge hosted storage and processing.
- Deciding to build an app that doesn't store any data.
- Using a tool that allows you to deploy your infrastructure as code and move it between regions (AWS CloudFormation, for example) can make it easier to support data residency (note: you'll still need to make sure you're configuring your templates correctly).
- You can read more about how this helped partner K15t implement data residency here →
- Choosing a trusted hosting provider that enables data protection and data loss prevention.
You can read more about Atlassian's approach to cloud data protection, including how we've built data protection directly into our platform, in our data protection whitepaper.
To help demonstrate some of these principles in action on the Marketplace, we reached out to Platinum Marketplace Partner JXL, who has seen rapid growth on the Marketplace thanks in part to their secure by design approach.
Case Study: JXL for Jira
Built by former Atlassians, JXL for Jira is an all-in-one issue editor and organizer that allows teams to manage work at any scale in a spreadsheet format. JXL was built with security and customer trust in mind, so data never leaves a customer's Atlassian site. Here’s what JXL’s co-founders had to say about their approach:
How is JXL built to protect customer data?
We have designed JXL in a purposeful architectural approach where the web experience is completely decoupled from data and logic. Prebuilt, static web pages and assets are served from an efficient global edge network without any sensitive data. The app then speaks from the user's browser to Jira APIs to retrieve and store data.
There is no external data storage backend whatsoever and all data is stored in Jira. Customer Jira data never leaves their site. This makes JXL incredibly secure, scalable, fast, but also maintainable, economic, and environmentally friendly. Everyone wins.
How do you keep data protection in mind as you continue to add new features?
Our customers’ data belongs to our customers. We refuse to store any of it outside of Jira. Atlassian keeps data secure, provides recovery measures, allows customers to choose a geographic region where their data resides, and much more. We leverage all that instead of re-building it ourselves.
When building new features, we ask ourselves:
- How can we design new features and capabilities in a way that data can be efficiently retrieved and stored via Jira APIs?
- What is the absolute minimum in terms of data access privileges and permissions we require to make it work?
- How can we avoid or minimize any transferring and processing of data other than between the client and Jira servers?
- When it comes to essential analytics, error, and performance monitoring, what do we need to do to guarantee that no data is captured, and origins are completely anonymized?
How does this way of building ultimately help your customers?
Security and privacy are built into the fabric of the JXL app, infrastructure, processes, and services, so customers can rest assured that their data is always protected. Hence our Atlassian Cloud Fortified badge and Bugcrowd bug bounty program record.
We frequently receive positive feedback on our unique approach and security posture from customers and prospective customers assessing our app. In both Cloud and Data Center it's as secure as a Jira app can be.