Upcoming changes to Data Center App Security process

Announcements
, , ,
1

At Atlassian, one of our goals is to make sure customers can trust our software is safe and secure. That is why every Data Center product at Atlassian is subject to a third-party dependencies security scan for known vulnerabilities. It’s critical to address vulnerabilities as soon as possible to ensure our customers can continuously trust the Atlassian Ecosystem. This way we’ll be able to detect potential issues early enough to reduce any risks for our customers.

Over the course of years we’ve seen the evolution of mechanisms used in Atlassian Data Center Engineering to discover security vulnerabilities. There are security scanners, Bug Bounty Program, and more. Customers rely on Atlassian software and trust us with their data every day.

Atlassian Data Center products are part of a thriving Ecosystem and the vast majority of deployments host multiple Data Center apps. The security of such a complex setup depends on the security of each of its components.

We want to share our experience in this area and help partners align with Atlassian Security Standards.

What is changing?

We’re proceeding with the extension of the Data Center app approval process and introducing a third-party security scanner for all Data Center apps.

Since November 2022 all apps submitted for Data Center app approval have to be free from critical- and high-severity security vulnerabilities in third-party dependencies. Learn more about the technical aspects of the security scan process.

Starting from July 2023, we’ll start tracking Data Center app vulnerabilities in the Atlassian Marketplace Security Jira project. Atlassian Marketplace Security (AMS) is our one-stop-shop for vulnerability management, where partners can go to review all their vulnerabilities, statuses, due dates, sources, and severities. All issues in AMS describe the vulnerability in detail, and all questions about an issue can be addressed in the comments of the issue. Learn more about AMS.

What do I need to do?

Please review our Security Bug Fix Policy for Marketplace apps that outlines Atlassian’s security expectations of developers who host apps on the Atlassian Marketplace, specifically regarding security vulnerabilities.

We’ll also reach out to partners who own apps with the highest number of detected vulnerabilities. We want to ensure that we create enough room for you to discuss and act on the security scanner results.

Last but not least, please ensure that the security contact in your partner profile is up to date and that you follow Vulnerability review practices for Atlassian marketplace partners. It’s important to complete those steps before the rollout of the security scanner integration with the Atlassian Marketplace Security Jira project.

Thank you for taking this seriously. Please review the technical aspect of dependency scanning and consider including it into the CI/CD pipeline of your Data Center app.

Please note that our team will also communicate this information via ECOHELP tickets. If you have any questions or concerns, please don’t hesitate to reach out to us through the ECOHELP tickets.

1 Like
2

There was lengthy discussion of this in the past from many vendors.

What scanner is Atlassian using? Why is it closed source, why can I as a vendor not proactively include identical scanning in my CI pipeline?

Why must I wait for Atlassian to do scanning which may have conflicting results with the scanner I choose to use in CI?

Please can I request a proactive scan of all ScriptRunner apps, and the results of that scan to be passed on, as a matter of urgency.

8 Likes
3

That lengthy discussion can be found here: Upcoming changes to Data Center App Approval

@OleksandrKravchenko, can you please elaborate how Atlassian thinking has evolved since @kbrazulewicz last comment?

6 Likes
4

+1 for to run the scanner on our infrastructure otherwise you’re asking us to to be reactive rather than proactive (which isn’t that responsible).

If you can’t provide the scanner - can we get a write up of what it does and scans for?

Also - (and I acknowledge that this is a bit off topic )who at atlassian has access to the AMS project and how is it secured?

9 Likes
5

Can Atlassian please ensure we have exemptions for security vulnerabilities which are required to work in the Atlassian environment, such as:

  • Vulnerabilities brought in by AtlasKit, or by AtlasKit components provided by Atlassian, or by third-party dependencies required by those two?
  • Vulnerabilities brought in by the Atlassian Connect Spring Boot (ACSB) or the Atlassian Connect Express (ACE) framework?
  • Edit - for Server apps: Vulnerabilities that Confluence or Confluence plugins include and that are ‘provided’ scope in our app. Those depend on the customer’s version of Confluence, not on the customer’s version of our app (Thank you @jasonboileau, although I’m more worried about NPM vulnerabilities, as it is not obvious when they are due to us or not).

Since Atlassian wants to automate, it is very important that automations don’t get our accounts flagged just because Atlassian requires a vulnerable library.

1 Like
6

Likewise for vulnerabilities that Confluence includes and that are ‘provided’ scope in our app. We do not control what version of the library is used, so it doesn’t make any sense for us to spend time coercing maven to not include it in the dep tree (which can lead to fragile builds).

1 Like
7

Not providing the scanner or access to the scanner is insanity. How are vendors meant to verify changes when an app was flagged?
Wait for Atlassian to run it for them and wait for the results? “The estimated wait time for your result is currently < 1 week” LOL

1 Like
8

I have real doubts that a scanner behind Marketplace Support is in any way shape or form helpful and actionable by vendors.
No disrespect to the people behind Marketplace Support servicedesks, but getting an initial reply can take days and if we are expected to resolve these issues quickly then a days delay to get results is not workable.
From my interaction with Marketplace Support I would think they need far more people to service all the requests. My app get flagged in alert state for a CloudFortified metric and it toke more then a week to get an initial response.
If the same can be expected for this, then I would not be surprised if vendors could find themselves in an infinite results wait loop. where a scan for verify a fix would lead to another vuln resulting in a new scan and wait and so on.

Ideally the scanner would be made available to vendors to include it in there own build pipelines.
But if this is not possible, then at least provide an API where vendors can upload an app to to have it scanned. Then we can include this API in our build pipelines.

As others have said, proactive works, reactive just results in more work and time wasted.

3 Likes
9

Hi @rlander,
Atlassian’s scanner is a complex solution that supports the collection of results from more than one scanning tool. Providing Atlassian’s scanner as a public service is not on our roadmap as of now. However, in the near future, we are going to work on a solution or documentation that will allow you to have results closer to Atlassian’s scanner.

10

Hi @danielwester,
AMS tickets will be visible only for security contacts in your Partners profile on the marketplace.

11

Thanks @OleksandrKravchenko for that but I was wondering who inside Atlassian has access to them. If it’s wide open to all of Atlassian that represents a larger concern. While this concern exists today for our Cloud customers - those vulnerabilities are “transient” due to the nature of the delivery in cloud.

In a DC world - you’ll have a list of vulnerability per version with details I’m assuming which is quite concerning if it’s widely available to anyone at Atlassian.

So my question remains - who at atlassian has access to AMS and how is this audited?

4 Likes
12

Hi @aragot ,
We realize the issue you described. You can be sure that we are not going to start the hiding process of apps that are affected only by vulns in Atlassian dependencies.

2 Likes
13

Does Atlassian recognise that this is an issue? You want a secure platform, but you want to keep part of the security tooling behind closed doors.

You are willingly allowing fragmentation of tooling among vendors, which then has to be sanity checked again by a tool we have no access to.

in the near future, we are going to work on a solution or documentation that will allow you to have results closer to Atlassian’s scanner

This should be done before you roll the programme out, and should have been done months ago when this programme was first announced, and got community pushback.

Will this documentation cover both Maven and Gradle? It should not come with the assumption vendors use Atlassian’s SDK.

Security should be proactive, this programme is reactive if the tooling is not in the hands of vendors prior to publication.

6 Likes
14

@OleksandrKravchenko, I see that you are commenting on other feedback, can you also please respond to my question?

2 Likes
16

Hi @remie ,
Thank you very much for your patience.
The main change of this announcement is that starting from July 2023, we’ll begin tracking Data Center app vulnerabilities in the Atlassian Marketplace Security Jira project .

CC: @kbrazulewicz

17

Hi @UlrichKuhnhardtIzym1 ,
Providing Atlassian’s scanner as a public service is not on our roadmap as of now. However, in the near future, we are going to work on a solution or documentation that will allow you to have results closer to Atlassian’s scanner. Atlassian is always looking for possible improvements in tools and processes for users and Partners within our capabilities.

18

Hi @OleksandrKravchenko, thank you for your response. However, this was not what I asked.

Atlassian has had a lengthy discussion with vendors about exactly this topic (see Upcoming changes to Data Center App Approval) and as a result of that discussion, after hearing arguments from the Marketplace Partner community, Atlassian changed course and decided that it would suffice to provide a vulnerability report from any scanner the Marketplace Partner deemed fit. This way, Atlassian would not dictate which scanner to use, and each vendor could implement a proactive approach to vulnerability scanning.

It seems now with your announcement that Atlassian has changed course, 1.5 years after the initial announcement, without any discussions or consultations and is applying the policy change with a 1 month notice.

So my question is: why did Atlassian change course? Considering all the feedback provided in the initial thread (which are repeated once again in this thread) from Marketplace Partners. Did you weight that feedback and did you come to a different conclusion? If so, why? Or did you discard that feedback and should we have the same discussion all over again? And if so, can you please postpone your policy change until we’ve actually had that discussion?

It seems silly to me that we are having the same talk without having any clue as to why Atlassian is changing course.

CC: @tpettersen

PS: @OleksandrKravchenko if you are not the person responsible for making this decision and are merely executing on the decided policy change, please tag the person with whom we should have this conversation instead.

5 Likes
19

Thank you @danielwester, for clarifying your question.
I am not sure whether the information about internal access can be disclosed publicly.

CC: @kbrazulewicz

20

It’s not clear to me, has the scanner already been live all this time? How would we know?

Did I miss a communication that it was now live? Should I assume we’re in the clear based on no tickets so far?

This post comes across as introducing the scanner one month from now, but I get the sense actually this is just about AMS tickets.

Let me be clear, Atlassian is being prescriptive by enforcing tools as part of the programme, and keeping them locked away from vendors.

I have escalated this via our TPM, I do not find the answers satisfactory, or in the best interests of vendors, and the security of our mutual customers.

21

That’s quite worrisome. So I take it then that any Atlassian Employee, Contractor etc is able to see any app vendors vulnerabilities?

I really would encourage the Atlassian Security team to take a step back and start to reconsider what they’re doing here. We need a program from them that is proactive and not reactive. We also need the program to be managed properly so that it’s not a risk for partners in either the workflow/identification (ie let us be able to run this toolset at release time) and be comfortable that the vulnerabilities aren’t going to be leaked.

10 Likes