Additional information: Vulnerability tracking

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.

Issue types

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.

Workflow statuses

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:

ecoscanner vulnerability

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. The workflow statuses that do require manual intervention are Extension Requested and In Review. Pending Scanner Verification is optional.

Status	Transition trigger	Actions required
`To Do`	Ecoscanner will create all new scanner tickets in the `To Do` status.	Review and acknowledge the ticket by moving the status to `In Progress`
`In Progress`	This status indicates that you are triaging or working on patching the issue. If you think the issue reported to you is invalid or a false positive, transition the ticket to `In Review`	Patch the issue.
`In Review`	Transition the ticket to this status when you need help from the Atlassian Security team and leave a comment on the ticket of what you need help with.	Atlassian Security will review your question and help determine if the issue is a true false positive or a won’t fix situation. The ticket will be transitioned to the according status after.
`Pending Scanner Verification`	Transition the ticket to this status when you have fixed the issue. This status is optional because Ecoscanner will automatically verify if the issue has been patched and close out the ticket for you.	The Ecoscanner will automatically check daily if the issue has been patched and if it is, will transition the ticket to `Patched`.
`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.	Waiting on Atlassian Security team to review the security issue. No action from partner needed.
`Patched`	Ecoscanner will transition the ticket for you to `Patched` once it has verified the issue has been patched.	The issue is resolved. No further action required.
`False Positive`	Transition the ticket to `In Review` if you think the issue is a false positive. You do not have the ability to transition the ticket to `False Positive` without review from Atlassian Security.	Atlassian Security will help determine if the issue is a true False Positive.
`Won't Fix`	Transition the ticket to `In Review`	Atlassian Security will help determine if the issue is a Won’t Fix situation.

Fields

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.

If you have any questions about how to interact with the AMS project, please reach out to the Ecosystem security team through our service desk.