Vulnerability Management Guide for Atlassian Marketplace Partners
Overview
Managing vulnerabilities is critical in maintaining a strong security presence in Atlassian’s Marketplace. This guide helps developers access vulnerability data, understand ticket fields, and take action. Reference this guide when signing up to address vulnerabilities, learning about our different ticket fields, and when determining which status is appropriate for your ticket.
For information regarding Atlassian’s expectations regarding vulnerabilities in the Marketplace, please reference the Security Bug Fix Policy.
The Atlassian Marketplace Security (AMS) Jira Project is the one-stop-shop for vulnerability information, tracking, and communication. In AMS, developers can directly communicate with the Ecosystem Security Team via comments in the AMS ticket, and prioritize all vulnerabilities by filtering by Remediation Due Date or Vulnerability Severity Level. For general questions regarding Atlassian Marketplace Security (AMS), vulnerability tracking, or ticket statuses, contact the Ecosystem Security team by clicking here.
Access to AMS
Atlassian requires apps to identify at least one person as a security contact in order for them to respond to AMS tickets. Security contacts are responsible for maintaining a strong security posture by following our Security Requirements and Security Bug Fix Policy. Atlassian may remove your app if you have no one identified as a security contact, since security contacts receive vulnerability tickets in AMS, and patching vulnerabilities is a requirement to host apps in the marketplace.
Follow the steps below to access vulnerability information in AMS:
-
Create an ecosystem.atlassian.net account by clicking this link.
-
Once your account is created, add your email address as a security contact by following the instructions in this link. When you complete this step, you will be automatically added to all the vulnerability tickets that belong to your organization. Please note that this process may take up to 24 hours for existing tickets.
-
Explore the partner dashboard to learn more about all your vulnerabilities.
An organization may add as many security contacts as they like. Each security contact will receive email updates about new and pending vulnerabilities. Additionally, security contacts will be listed as either an Assignee or Partner Participant in AMS tickets.
Ticket Types, Fields, and Definitions
The below table outlines each ticket type.
| Ticket Type | Definition |
|---|---|
| Bug Bounty Vulnerability | Vulnerabilities discovered through a Bug Bounty Program. Follow these links to learn more about the Marketplace Security Bug Bounty Program or the Vulnerability Disclosure Program. |
| EcoScanner Vulnerability | Vulnerabilities discovered through a scanner. |
| Security Vulnerability | Vulnerabilities discovered through app reviews, testing, and the self-assessment. |
The below table outlines each ticket field, it’s definition, and which ticket type(s) it applies to. As a reminder, not all fields are present in all ticket types. If a ticket field shows up on your AMS ticket but is not listed below, then it’s for internal Atlassian use only and can be ignored.
| Field Type | Ticket Field | Definition | Bug Bounty Vulnerability | EcoScanner Vulnerability | Security Vulnerability |
|---|---|---|---|---|---|
| Vulnerability Details | Description | Describes the vulnerability in detail, and usually includes steps to reproduce the vulnerability, and impact of the vulnerability. |  | | |
Bugcrowd Submission URL | Link to the Bugcrowd submission. | |  | | |
CVSS V3 Score | The vulnerability’s score based on the CVSS open framework. | | | | |
CVSS V3 URL | Link to the CVSS calculator justifying the score. | | | | |
Vulnerability Severity Level | A vulnerability’s severity, which is one of the following: P1 - Critical (Critical) P2 - Severe (High) P3 - Moderate (Medium)P4 - Low (Low) P5 - Informational | | | | |
| Timing Considerations | Remediation Due Date | The date the vulnerability needs to be fixed by. | | | |
Scan Timestamp | The time when the vulnerability was last found. This updates daily. | | | | |
SLA Violation | An indicator of whether a due date has been violated. | | | | |
Triage Due Date | The date when the partner needs to accept or reject the vulnerability. NOTE: Bug bounty vulnerabilities are auto-accepted after two weeks if there is no response. Once accepted, the timeframe for resolution begins, which is based on the Security Bug Fix Policy. | | | | |
| Stakeholders | Assignee | The Security Contact who is responsible for responding to the vulnerability. NOTE: This field can be changed by any user within an organization. | | | |
Partner Particpants | Security contacts who can review, work on, and close a ticket. | | | | |
Reporter | The bot or person who submits the vulnerability. | | | | |
| Partner and App Details | Hosting | Hosting type for the app, which is either cloud, data center, or server. | | | |
Marketplace App Key | The app key of the app where the vulnerability was identified. | | | | |
Marketplace App Name | The name of the app where the vulnerability was identified. | | | | |
Partner Dashboard | Link to vulnerability dashboard. | | | | |
Partner ID | Identifier for a partner where the vulnerability was identified. | | | | |
Partner Name | Name of a partner where the vulnerability was identified. | | | | |
Source | How the vulnerability was discovered, which is one of the following: Bug Bounty Atlassian (Internal) Customer Report Partner Report Security Review | | | |
Statuses, Workflows, and Defintions
Vulnerabilities may have different ticket statuses with different actions associated with each status. In this section, we outline each status and the associated action by ticket type, which varies by Bug Bounty Vulnerability, EcoScanner Vulnerability, and Security Vulnerability.
Bug Bounty
Ticket Type = Bug Bounty Vulnerability. These vulnerabilities are discovered through a Bug Bounty Program. The following table and workflow represent Bug Bounty Vulnerabilities only.
Bug Bounty Vulnerability Statuses
| Status | Definition | Action |
|---|---|---|
Needs Partner Review | Vulnerability is discovered and requires triage. | Triage or validate the vulnerability, and then change the status based on the circumstance. |
Needs Patch | Vulnerability is validated, scored, and pending a fix. This status is prompted by an Unresolved status in Bugcrowd. | Plan to fix the vulnerability by the Remediation Due Date. |
Extension Requested | Need more time to fix the vulnerability. | N/A; Atlassian is reviewing the request. NOTE: Atlassian does not accept extension requests unless the extension falls into one of our exempt categories. To view exempt categories, click here. |
Atlassian Input Requested | Vulnerability is pending review by Atlassian’s Ecosystem Security team. | When stuck, comment in the ticket with your question for the Atlassian Ecosystem Security team, and move the ticket to this status. |
Waiting for Release | Vulnerability has been fixed, but the fix has not yet been released. | Optional: Communicate the release date before transitioning a ticket to this status, and ensure the release date is prior to the Remediation Due Date. |
Patched | Vulnerability has been fixed. This status is prompted by a Resolved status in Bugcrowd. | N/A |
Duplicate | Vulnerability has already been reported elsewhere. This status is prompted by a Duplicate status in Bugcrowd. | Link to the original AMS issue [in AMS] before transitioning a ticket in Bugcrowd to this status. |
Won't Fix | Vulnerability is reviewed, but the risk is accepted. This status is prompted by one of the following statuses in Bugcrowd: Not Applicable, Out of Scope, or Won't Fix. | Provide an explanation [in AMS] for why the vulnerability risk is acceptable, and how it does not put Atlassian customers at-risk. |
False Positive | Vulnerability is not actually a security vulnerability. This status is prompted by a Not Reproducible status in Bugcrowd. | Provide an explanation [in AMS] for why you believe this vulnerability is not actually a security vulnerability. |
Bug Bounty Vulnerability Workflow
Security
Ticket Type = Security Vulnerability. These vulnerabilities are discovered through app reviews, testing, and the self-assessment. The following table and workflow represent Security Vulnerabilities only.
Security Vulnerability Statuses
| Status | Definition | Action |
|---|---|---|
Needs Partner Review | Vulnerability is discovered and requires triage. | Triage or validate the vulnerability, and then change the status based on the circumstance. |
Needs Patch | Vulnerability is validated, scored, and pending a fix. | Plan to fix the vulnerability by the Remediation Due Date. |
Extension Requested | Need more time to fix the vulnerability. | N/A; Atlassian is reviewing the request. NOTE: Atlassian does not accept extension requests unless the extension falls into one of our exempt categories. To view exempt categories, click here. |
Atlassian Input Requested | Vulnerability is pending review by Atlassian’s Ecosystem Security team. | When stuck, comment in the ticket with your question for the Atlassian Ecosystem Security team, and move the ticket to this status. |
Waiting for Release | Vulnerability has been fixed, but the fix has not yet been released. | Optional: Communicate the release date before transitioning a ticket to this status, and ensure the release date is prior to the Remediation Due Date. |
Patched | Vulnerability has been fixed. | N/A |
Duplicate | Vulnerability has already been reported elsewhere. | Link to the original AMS issue before transitioning a ticket to this status. |
Won't Fix | Vulnerability is reviewed, but the risk is accepted. | Provide an explanation for why the vulnerability risk is acceptable, and how it does not put Atlassian customers at-risk. |
False Positive | Vulnerability is not actually a security vulnerability. | Provide an explanation for why you believe this vulnerability is not actually a security vulnerability. |
Security Vulnerability Workflow
EcoScanner
Ticket Type = EcoScanner Vulnerability. These vulnerabilities are discovered through a scanner. The following table and workflow represent EcoScanner Vulnerabilities only.
EcoScanner Vulnerability Statuses
| Status | Definition | Action |
|---|---|---|
To Do | Vulnerability is pending a fix. | Plan to fix the vulnerability by the due date, and transition the status to In Progress. |
In Progress | Vulnerability is being fixed. | Fix the vulnerability by the Remediation Due Date. |
Extension Requested | Need more time to fix the vulnerability. | N/A; Atlassian is reviewing the request. NOTE: Atlassian does not accept extension requests unless the extension falls into one of our exempt categories. To view exempt categories, click here. |
In Review (Atlassian Input Requested) | Vulnerability is pending review by Atlassian’s Ecosystem Security team. | When stuck, comment in the ticket with your question for the Atlassian Ecosystem Security team, and move the ticket to this status. |
Patched | Vulnerability has been fixed. | N/A NOTE: There is no action required once you fix EcoScanner vulnerabilities, since EcoScanner will automatically detect the fix, if fixed correctly. |
Won't Fix | Vulnerability is reviewed, but the risk is accepted. This status is prompted by a review by the Atlassian Ecosystem Security team. | Transition the ticket to In Review and provide an explanation for why the vulnerability risk is acceptable, and how it does not put Atlassian customers at-risk. |
False Positive | Vulnerability is not actually a security vulnerability. This status is prompted by a review by the Atlassian Ecosystem Security team. | Transition the ticket to In Review and provide an explanation for why you believe this vulnerability is not actually a security vulnerability. |
EcoScanner Vulnerability Workflow
Rate this page: