Rate this page:
Atlassian uses the Atlassian Marketplace Security project (AMS) to track vulnerabilities in Marketplace apps. While vulnerabilities can be reported through many sources, AMS is the single source of truth for security issues.
This page provides additional information about how the AMS project is structured.
The AMS project has two issue types, each with its own workflow.
|Security Vulnerability||Represents vulnerabilities reported through bug bounty, pentesting, and manual assessment. This issue type has a more complex workflow designed for more in-depth manual reviews.|
|Ecoscanner Vulnerability||Represents issues reported by scanners. This issue type has a more simplified workflow allowing for greater automation.|
The Security Vulnerability workflow contains the following statuses:
|Status||Transition trigger||Actions required|
|Atlassian Security team will transition the issue to this status when the issue is confirmed to be valid and CVSS scored.||Remediate the security issue within the SLA specified in the ticket.|
|Transition the ticket to this status when the issue requires triage or validation from the Ecosystem Security team.||Waiting on Atlassian Security team to review the security issue. No action from partner needed.|
|Transition the ticket to this status when the fix has been implemented, but has not yet been released.||Ensure that the release timeline meets the SLA.|
|Transition the ticket to this status when you are not able to meet the remediation SLA. Provide a detailed remediation plan and a proposed new due date.||Atlassian Security will review and either approve or deny the request. The ticket will be transitioned to with the new due date.|
|Transition the ticket to this status when the vulnerability has been remediated.||The issue is resolved. No further action required.|
|Transition the ticket to this status when you think the issue is a duplicate of another.||Provide the reference to the original issue.|
|Transition the ticket to this status when you think the issue is a false positive.||Provide an explanation for why the issue is not a security vulnerability or is not exploitable.|
|Transition the ticket to this status when you would like to accept the security risk and not remediate the issue.||Provide reasons for choosing to not remediate the issue and potential mitigating controls.|
The Ecoscanner Vulnerability workflow contains the following statuses:
The main distinction here is that most of these workflow steps are automated and will not require manual intervention. For example, patches are verified automatically by the scanner. If the scanner no longer detects the vulnerability, the issue will be automatically resolved.
There is a substantial number of fields for tracking information pertaining to a vulnerability. Partners should pay particular attention to the fields listed in the table below. The remaining fields which are not listed are for administrative use by Atlassian Security.
|Detailed description of the vulnerability, usually including reproduction steps and impact.|
|User assigned to the issue is primarily responsible for driving the vulnerability remediation effort.|
|Additional users from the partner organization’s team who will need to have visibility into the issue.|
|If the source of the report is Bugcrowd, this field will contain a link to the Bugcrowd submission.|
|CVSS score of the vulnerability.|
|CVSS score link. The URL will be used to justify how the severity level was determined.|
|Represents the severity level of the vulnerability, usually based on the CVSS score range.|
|The original source of the vulnerability, including Bug Bounty, Atlassian, customer report, security review, and more. Note that scanner-found vulnerabilities have their own issue type.|
|The date by which the partner must review and either accept or reject the vulnerability.|
|The date by which the partner must fix the vulnerability.|
|This field highlights if the ticket has violated either the Triage or Remediation SLA.|
Rate this page: