Hi All,
Thanks for the feedback and suggestions regarding the RFC. Just to emphasize, app signing is one of the steps we’re considering, along with other capabilities like Multi-factor authentication and allowing Web Sudo operations that are limited by IP addresses, as part of our efforts to enhance our security stance. App signing serves several key purposes:
- Verifying Plugin Integrity: It ensures that both custom and marketplace plugins haven’t been tampered with since they were signed, maintaining their integrity.
- Establishing Trust and Authenticity: By confirming that a plugin originates from a genuine source rather than a malicious entity, app signing boosts trust and authenticity.
- Protection Against Attacks: It assists in safeguarding against different attack vectors, such as uploading local JARs via API/UI in UPM or through the file system, and marketplace installations via UPM.
Our proposed solution
The solution we are leaning on is option 3. This option gives us more confidence in controlling the signing process while adhering to regulations and policies. We also considered option 1, which is similar to the Android APK signature schema v1. This schema has shown some limitations in terms of performance and security. This is because only entries that were part of the archive during the signing are taken into account, which leaves some blind spots in terms of attack surface.
Signing the entire archive allows the signing process to be performant and secure. This approach has been adopted since the APK signature schemas v2. However, unlike Android, we decided not to embed the signature into the app bundle. This process would require some byte manipulations and make the double-signing process complex.
In terms of impact, option 3 allows us to gradually phase this project and implement the “Marketplace Trust zone” independently. This should already help reduce some risks with a lesser impact on app vendors. Only Atlassian and customers having custom apps are required to sign apps. In this initial phase, Atlassian should automatically sign reviewed apps and their versions. Customers will be able to trust any public key or certificates stored in a dedicated folder. This should allow them to sign and install private or custom apps.
Also note, that already installed apps will not be required to be signed in. However they need to be signed in case of any upgrades (new versions installation).
Addressing some recurring themes
We’re taking an iterative approach here, gradually addressing the issues at hand. We’re exploring various aspects of the app signing like Atlassian app signing service, mitigating supply chain attacks, among other concerns. Some of these aspects are potential candidates for future iterations.
A few recurring themes have surfaced from our discussions:
-
Handling Custom Plugins: It’s crucial that customers retain the ability to install custom or private plugins. We’re considering options such as signing these plugins and locally trusting their key/certificate. During the initial phases, we’ll maintain support for downgrading through the same process. Support for custom apps is essential, and customers will be able to trust any certificates dropped in a dedicated folder.
-
Exploring Holistic Solutions: What we’ve outlined in this RFC represents the initial stage of app signing. We anticipate its evolution over time. For example, future iterations could involve verifying signatures from both the vendor and Atlassian. This approach would mitigate single points of compromise, provided there’s a way to ensure the safety of vendor signatures for customers.
This project is a long-term endeavor, requiring several iterations for a progressive rollout and ensuring backward compatibility.
-
App signing service: Regarding the suggestion of having an “App signing service” by Atlassian, it’s indeed a promising idea. Such a service could alleviate the burden of key/certificate management for app vendors and enable Atlassian to enforce robust security policies regarding key rotation and revocation. This could be considered once app vendors are mandated to sign their apps.
-
Enhancing Marketplace app review process : Agreed, the current marketplace review process doesn’t catch malicious code. However, we conduct regular checks on existing Marketplace apps to ensure they don’t contain security vulnerabilities. We’ve forwarded this feedback to our Marketplace team and will keep you updated on our progress.