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.
Issue Type | Purpose |
---|---|
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 |
---|---|---|
Needs Patch | 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. |
Needs Security Review | 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. |
Waiting for Release | 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. |
Extension Requested | 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 Needs Patch with the new due date. |
Patched | Transition the ticket to this status when the vulnerability has been remediated. | The issue is resolved. No further action required. |
Duplicate | Transition the ticket to this status when you think the issue is a duplicate of another. | Provide the reference to the original issue. |
False Positive | 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. |
Won't Fix | 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.
Field | Purpose |
---|---|
Summary | Vulnerability summary. |
Description | Detailed description of the vulnerability, usually including reproduction steps and impact. |
Assignee | User assigned to the issue is primarily responsible for driving the vulnerability remediation effort. |
Partner Participants | Additional users from the partner organization’s team who will need to have visibility into the issue. |
Bugcrowd Submission URL | If the source of the report is Bugcrowd, this field will contain a link to the Bugcrowd submission. |
CVSS V3 Score | CVSS score of the vulnerability. |
CVSS V3 URL | CVSS score link. The URL will be used to justify how the severity level was determined. |
Vulnerability Severity Level | Represents the severity level of the vulnerability, usually based on the CVSS score range. |
Source | 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. |
Triage Due Date | The date by which the partner must review and either accept or reject the vulnerability. |
Remediation Due Date | The date by which the partner must fix the vulnerability. |
SLA Violation | This field highlights if the ticket has violated either the Triage or Remediation SLA. |
Rate this page: