These changes are now live as part of our 2025 update to marketplace security policies. Read more about these updates here: Partner Portal Blog
To uplift the security baseline for all Marketplace apps, we have introduced new security checks for onboarding apps and publishing new app versions. This page explains what to expect when developers submit their new app or publish a new version to their existing listing on the Atlassian Marketplace.
Overview of New Security Workflow
We have introduced below security checks for onboarding marketplace apps and app updates:
Review signals: Responses are automatically evaluated using warning (⚠️), and fail (🚫) signals. Fail signals will block your app from listing on the Marketplace. Read more about these questions at Security Questionnaires for Marketpalce apps
Partner Security Questionnaire
Partners must also complete a partner security questionnaire covering security practices, infrastructure, development processes, policy documentation, and vulnerability management.
Partner Security Questionnaire responses are for informational purposes and are not evaluated or block the app approval process.
Partner Identity Verification
Atlassian has partnered with a third-party vendor to conduct Know Your Customer (KYC) and Know Your Business (KYB) verifications. All partners will be required to complete this process when onboarding new apps to the Marketplace. For detailed information about this process, see Due diligence business and identity verification for Marketplace Partners.
Identity Information Collection: Complete the Identity Information Collection form with business and personal information
Individual verification: Use our vendors Identity platform to confirm your identity with identification documents
Business verification: Atlassian will verify your business identity using the information provided
Important: Only NEW APP submissions will require Partner Verification tickets. App updates (both major and minor) will NOT require this process. Also, If you completed Partner Verification as a result of a previous app submission/update, you will NOT be required to undergo this process again for future app submissions/updates.
Vulnerability Scanning
Automated vulnerability scanning is performed during app onboarding and app updates (major & minor). Any detected critical or certain high severity vulnerabilities must be resolved before completing the app onboarding or publishing a new version.
How vulnerability scanning works
Automated scanning: When you submit your app for approval, we automatically scan for vulnerabilities and report any findings on the ECOHELP ticket.
Resolution required: If Critical or certain High severity vulnerabilities are found, the approval process will be blocked and ECOHELP ticket will be moved to Awaiting Resubmission status. You must resolve all reported vulnerabilities before your app can be approved.
Re-scanning: When a vulnerability is found, your initial ECOHELP ticket will be rejected, you must address the identified issues and resubmit your app through the vendor portal. This will generate a new ECOHELP ticket and trigger another vulnerability scan to confirm that all issues have been resolved.
What gets scanned
Security Requirements: Security requirements for Cloud and DC apps, more information on what we scan for can be found at Ecoscanner and DC Scanners DAC pages.
Dependencies: Known vulnerabilities on Third-party libraries
Scan Findings Reported on AMS
When critical or certain high-severity vulnerabilities are found during the scanning process, an AMS (Atlassian Marketplace Security) Jira ticket is automatically raised to track the security findings. These tickets will be shared with you on the ECOHELP app approval ticket for your review.
Access to AMS
AMS (Atlassian Marketplace Security) is the Jira project where security vulnerabilities and findings related to your Marketplace apps are tracked. Access to AMS allows you to view, comment on, and manage security tickets raised for your apps.
Who can access: Only security contacts listed in your Marketplace Partner account have the appropriate permissions to access AMS tickets related to your apps.
Each AMS ticket includes a customfield called "App Version Visibility" and this custom field distinguishes AMS tickets related to onboarding a new app or publishing a new version from standard scan tickets:
New submissions or version updates: When the customfield is set to "Unpublished" - the AMS ticket belongs to the app/version being reviewed before making it available to customers
AMS tickets on Unpublished Versions are Not Enforced
AMS tickets created during the app approval process (Unpublished app version visibility) are intended solely to provide partners with visibility into vulnerabilities that are preventing the app from being onboarded. These tickets will automatically close within 7 days.
For Unpublished app versions:
AMS tickets are not used for enforcement actions such as hiding apps or Badge Removal.
Any Remediation Due Dates attached to these tickets do not need to be followed. The only requirement is to resolve the vulnerabilities before the app can be approved and published.
False Positives
If you believe that a vulnerability raised is a false positive or you disagree with the assessment, you can provide justification by commenting directly on the AMS ticket and/or on the ECOHELP ticket. Atlassian will review your justification, and if agreed, the AMS ticket will be updated to "False Positive" or the appropriate status.
Important: Even if the scan finding is determined to be a false positive, your original ECOHELP ticket will have been rejected when the vulnerability was first identified. You must resubmit your app through the vendor portal after the AMS ticket is updated to ensure the approval process continues.
This workflow ensures that security issues are addressed before any app version becomes available to customers.
Vulnerability Scanning Workflow for App Updates
We've made important changes to how vulnerability scanning works for different types of app updates to clarify confusion and streamline the process.
Major version updates
Major version updates follow the full approval workflow:
Require security questionnaires
Require vulnerability scanning
Require manual review by the Marketplace team
May require Partner Verification (if not already completed)
Minor version updates
New Security Workflow differs for Cloud and DC Minor version updates:
What happens with Cloud minor version updates?
There will be no security checks involved for a Cloud app minor version update
What happens with DC minor updates?
ECOHELP ticket creation: Minor updates will open a Standard ECOHELP ticket to facilitate the app scanning process
Vulnerability scanning: Critical vulnerabilities are still checked and will block the update if found
Automatic closure: These tickets should automatically close within minutes and should NOT require interactions from Partners or Marketplace Support Engineers
No additional requirements: Minor updates do NOT require:
Security questionnaires to be completed
Partner Verification (KYC/KYB) to be completed
If vulnerabilities are found
If critical vulnerabilities are detected in a minor update:
The ECOHELP ticket will be rejected and app update will be blocked
A linked AMS ticket will be provided in the comments
You must resolve the vulnerabilities and publish a patched version to proceed, and it will create a new ECOHELP ticket to initiate the rescan.
Privacy & Security Tab Questions for Cloud Apps
Completing questions for the Privacy & Security Tab will be mandatory for cloud app onboarding, new set of disclosures were added:
Required disclosures
Personal Access Tokens (PATs): Disclosure as to whether or not the app requires end users to provide Atlassian Personal Access Tokens (PATs)
Permission justification: Justification for the permissions requested by the app
Trust Center link: Partner "Trust Center" link to allow customers easier access to partner security materials (Optional)
These questions help customers understand the security implications of installing your app and make informed decisions about permissions and data access.