Vulnerability review practices for Atlassian marketplace partners

Running this play

Step 1 : Preparation

Understand your SLAs

1. Triage SLA : Partners are accountable for accepting or rejecting an issue within 2 weeks of it being reported.

2. Remediation SLA : Partners are expected to fix vulnerabilities in a timely manner once the vulnerability has been accepted. Depending on the severity of the vulnerability and the hosting type the timeframe varies. Review the Security Bug Fix Policy.

Step 2 : Goals

Set Your Security Goals

Identify what you want to change or improve about your security practices.

Start with only one or two goals - keep it simple. And if you can, apply the same goal or goals to all of your products and/or services - make it easy to track!

Measure Your Goals

Define your goals in a way that you can measure them and definitively say whether you've met the objective or not. Some examples of potential goals:

• 0 SLA violations in all apps (the ideal goal)
• 50% reduction in SLA violations

Write Down Your Goals

Once you are on board with the goals you've set, write them down and share it with everyone in your team - these are your declared objectives.

These goals can change over time. As you gather more information, you'll be able to make more informed decisions. The ultimate goal of this playbook is for you to have 0 SLA violations indefinitely.

Step 3 : Get access to your data

1. Add your email as security contact in partner portal - More information
2. Create an account using the email listed as security contact in ecosystem.atlassian.net

When you complete the above two steps you will be automatically added to all the vulnerability tickets that belong to your organization.

Once you have access to ecosystem.atlassian.net explore the partner dashboard

Step 4 : Prioritize your tickets

From the partner dashboard you will have access to all your vulnerability information spread across different sections for better visualization.

You should always aim to have 0 SLA violations but depending on the state of your tickets you might run into the following scenarios

When you have tickets in SLA violation

You should prioritize resolving the tickets in the following order

When you have 0 tickets in SLA violation

Thats great ! Now you can prioritize tickets that are at the risk of violating SLA’s

You can get this information from the AMS issues approaching SLA Violations widget in the dashboard.

The issues in this filter are tickets that are less than 7 days away from violating an SLA (Either Remediation SLA or Triage SLA) Prioritize to resolve the tickets in this filter before their due dates.

When you have 0 tickets in SLA violation and no tickets at risk of violating SLA

Thats fantastic ! You have a good security hygiene. You can now prioritize on resolving the tickets that are currently open. Approach the open ticket in the order of closest due dates.

You can get this information from the Open Security Issues widget in the dashboard.

Step 5 : Analyze your data

The dashboard also provides you 3 Pie Charts for your analysis of all the issues that have been reported so far

Issues by severity

• Higher number of P1 and P2 indicate a higher security risk to the customer
• Gives you a picture of the security awareness and maturity of the development team

Issues by vulnerability class

• Gives you an idea on what seems to be an area of concerns.
• Can this be addressed with a design change?

Issues by app

• Which app in your portfolio seems to be the most vulnerable?

It varies from organization to organization on how this data can be interpreted but share and discuss these observations with your internal teams.

Step 6 : Re-evaluate your objectives

Over time, you might see a decrease in the number of security SLA violations (ideally your team will maintain 0 SLA violations). This in turn will mean that your teams goals will need to evolve with your team.

Is it time to decrease the number of SLA violations in your goal? These goals should be reviewed regularly.