Hello, Atlassian Developer Community!
Earlier this year in March 2024, we asked for your feedback on RFC-39 regarding app signing to improve the security of our Data Center apps. Based on your input and feedback from our customers, we’ve made some updates, and we’re excited to announce the improved feature.
1. Overview and context
To boost the security of installed DC apps, we’re introducing a new feature that will restrict app installations to only those that are signed. This will help us to:
- ensure that apps are either from Atlassian Marketplace or manually uploaded by trusted sources
- prevent malicious actors from uploading harmful apps
The app signing feature will be gradually rolled out by April 2025, and customers will be able to enable it when convenient during a 90-day grace period.
2. Requirements
This feature was developed with security in mind. It focuses on protecting installed apps while allowing flexibility for custom and private builds.
| Requirement | Description |
|---|---|
| Air-gapped instances support | Air-gapped instances are able to install and verify apps offline. |
| Backward compatibility | Signature check has been designed to be compatible with current instances that have unsigned apps already installed. |
| Custom plugins support | Clients are able to install custom plugins. |
| Certificate management | Streamlined certificate management for both Atlassian and customers. |
| Extensibility | App signing is agnostic to apps’ type and can be extended to support additional features for further enhancements. |
3. Implementation
We’ve chosen the
Ed25519curve for app signing due to its high security and compliance with FedRamp and FIPS 186-5 standards.
The Atlassian Marketplace and Universal Plugin Manager (UPM) have been updated to sign and verify apps. UPM will support verification for Marketplace apps, custom apps, and private builds. The next diagram describes involved components.
3.1. Components
| Component | Description |
|---|---|
| Trust Store | Trusted certificates are stored in the Trust Store. It is crucial for system operators with file system access to set folder permissions carefully to ensure security. The user running the product should only have read-only access. UPM implements an ATST health check to verify that the Trust Store folder has the correct read-only permissions. |
| App Vendor (CI, CLI), App Vendor (private build) | These components represent the mechanism responsible for uploading plugins from the plugin vendor side (may be manual). |
| Custom Apps | Custom apps developed by customers and installed directly on their local instance. Signature verification only occurs when installing apps through UPM, not through the file system. |
| Marketplace | Atlassian Marketplace |
| Universal Plugin Manager | UPM |
4. Signature Verification
UPM offers support for 2 signature verification flows, enabling the verification of the following applications.
| Types of apps | Description |
|---|---|
| Marketplace apps | These are public or private apps hosted on the Atlassian Marketplace. |
| Private builds | Apps built by vendors and distributed directly to customers without being uploaded to the Marketplace. These are usually created for diagnostic purposes. |
| Custom apps | Apps built by customers to extend the functionality of our products |
4.1. Marketplace apps signature verification
Before this step, customers need to download the Atlassian certificate chain and save it in their Trust Store. Atlassian will provide the certificate bundle, which will be updated periodically.
Once the certificates are trusted, UPM uses them to verify the app’s certificate and signature before installation. The next diagram shows the steps involved.
At Atlassian Marketplace, we use temporary (ephemeral) keys to sign apps. This improves security because we don’t need to store a permanent signing key, reducing the risk if a key is ever compromised. This method is also used by new signing frameworks like Sigstore.
For air-gapped instances, you need to download both the app file and its signature file. Before installation, each app must have a matching signature uploaded to UPM. The app’s signing certificate is valid for one year from the time it’s downloaded.
Example of a signature file:
{
"signature": "39sn...",
"certificate": "LS0..."
}
4.2. Private builds and custom apps signature verification
Both private builds and custom apps use the same verification process. In both cases, customers need to trust the signing certificate by saving it in their local Trust Store.
This process is similar to the flow for Marketplace apps. The main difference is that the signing certificate is generated only once. Customers need to trust this certificate by saving it in their Trust Store. The signature file then only includes the app’s signature.
{
"signature": "pi99..."
}
5. Shared responsibility
While we’ve worked to minimize the impact, security is a shared responsibility between Atlassian, customers, and Marketplace partners. Your support in implementing these security measures is key to improving product security.
| Atlassian Marketplace | Customers | Marketplace partners | |
|---|---|---|---|
| Marketplace apps | |||
| Sign Apps |  |
||
| Tooling & documentation | |
||
| Key management | |
||
| Certificate management | |
|
|
| Custom apps | |||
| Sign Apps | |
||
| Tooling & documentation | |
||
| Key management | |
||
| Certificate management | |
||
| Private builds | |||
| Sign Apps | |
||
| Tooling & documentation | |
||
| Key management | |
||
| Certificate management | |
|
Thanks for being part of this journey!
Simple question: If I am a Marketplace Partner (aka App vendor) and upload to the Atlassian Marketplace. Only official public versions of the app.