Action required: Updates to security requirements for cloud apps

A few weeks ago, we shared a draft of new security requirements for Marketplace apps. Thank you all for weighing in.

We’ve incorporated your feedback into the final version, which we’ve now published here: Security requirements for cloud applications

One major concern we heard was around timelines - partners requested more time to fulfill the requirements than we had originally proposed. We’ve extended the date to bring apps into compliance, and partners now have until October 31, 2022 to meet the new requirements.

We’ve shared more background and detail about these updates on the developer blog. If you have questions, we’ve published a new FAQ page, and you can also ask questions in this thread.
Review this document for specific updates - security-requirements-status.pdf (111.7 KB)

3 Likes

Can you share a diff of what the specific changes and new requirements are? This information was originally included in the feedback PDF at https://community.developer.atlassian.com/uploads/short-url/huhZ63112jy86XqQjUaMrtJsL2T.pdf

4 Likes

With regards to point 6, we have a few apps whose baseUrls point directly to AWS services, like Cloudfront or API Gateway. Would this still fulfill the requirement, or would it be necessary to change these baseUrls to point to a separate domain name that belongs to us?

1 Like

Hi @boris we added the New tag to feedback PDF for review but haven’t included it in the actual page since it is not relevant for published requirements. New Tags in this PDF are still correct and can be used to find the updates. Sorry if it caused confusion.

@stephendeutsch1 Intent of the requirement is to maintain control of domain to ensure that domain is not expired and TLS certificates are valid, etc (Please see Implementation details for platform-specific requirements). It is not required to change the baseUrl as long as the domain is unique and controlled by you.

Does the Connect Security Requirements Tester will received updates to check some of these new requirements ?

3 Likes

@SrivathsavGandrathi would it be possible to start soft enforcement of these requirements through the Atlassian EcoScanner in either September or early October? That way, vendors will be notified of possible issues prior to the requirements going into effect and fully enforced.

4 Likes

@SrivathsavGandrathi Just to be clear, one of our baseUrls is something like the following:
https://abcdefghi.execute-api.us-east-1.amazonaws.com/
Obviously we don’t own amazonaws.com, but if we are fully in control of the subdomain, that is enough to meet the requirements?

It is relevant to published requirements. You need a change log. A change log needs to call out what is new, and what changed. It’s disrespectful of thousands of vendors time to ask us to manually recheck every single requirement whenever an update is made.

3 Likes

Does the Connect Security Requirements Tester will received updates to check some of these new requirements ?

would it be possible to start soft enforcement of these requirements through the Atlassian EcoScanner in either September or early October? That way, vendors will be notified of possible issues prior to the requirements going into effect and fully enforced.

@remie / @clement_garin While we are planning on adding more validation in near future, building towards our ultimate goal of validating that each security requirement is met by an app, we do not yet have a solid roll out date for new Ecoscanner checks. We will make sure to communicate timelines as they get decided to give enough prior notice. We will also plan on adding the new checks to Connect Security Requirements Tester arsenal.

Obviously we don’t own amazonaws.com, but if we are fully in control of the subdomain, that is enough to meet the requirements?

@stephendeutsch1 It is understandable and control on subdomain also meets the requirement.

It is relevant to published requirements. You need a change log. A change log needs to call out what is new, and what changed. It’s disrespectful of thousands of vendors time to ask us to manually recheck every single requirement whenever an update is made.

@boris We infact published the changelog here, https://developer.atlassian.com/platform/marketplace/changelog/#CHANGE-663 . I went ahead and updated the changelog to include specific updates document upon your suggestion which is now attached in this post. We will make sure to post these specific updates to changelog moving forward where partners can find the changes easily and also link it in actual page. Thank you for your feedback.

2 Likes

Hi @SrivathsavGandrathi ,
We are working on getting our apps in compliance with the new security requirements. However we came across the following:

In essence, it seems using AUI is not in compliance with the security requirements. However it is an official Atlassian supported UI library, and we are using it in our apps.
What is the stance of the security team on this?

1 Like

Hi @marc ,
I see that latest AUI is on 9.x version. While usage of eval in AUI has been addressed in the past, I have reached out internally to address any other usages. Please feel free to log any AUI security-bugs here. Meanwhile, for short term mitigation, please sandbox the code processed by eval() function.

Hi @SrivathsavGandrathi ,

Would you please justify and elaborate a bit more regards to the Authentication & Authorization requirement for Forge, it mentions that

Before making calls using asApp(), you must verify the expected permissions (for example, from product context) with the permissions REST APIs.

Does it mean that Atlassians expect there are always 2 APIs for every API call now? What is the purpose of making REST API calls from within a Forge app to validate that the app has permissions to make an API call?

2 Likes

Hi @SrivathsavGandrathi
Opened an issue for AUI: [AUI-5443] - Ecosystem Jira .

As AUI is consumed through a global script tag, we can’t sandbox the code. AUI has access to the whole DOM.

2 Likes

Hi @GaryFan,

Sorry for the delay, the purpose of this validation step is not to verify if the app itself has permission to make the call, it’s to verify if the invoking user has permission to make the API call. Since any user on the cloud site can manually invoke Forge app functions, there will be instances where the Forge app has more scopes than the invoking user leading to privilege escalation scenarios. Please read https://developer.atlassian.com/platform/forge/shared-responsibility-model/#authorization-of-requests-to-the-app for more information. Thanks!

We tried to apply the updated policies also to our Bitbucket Cloud connect apps.
However, it seems that Bitbucket Cloud Connect library itself uses eval(), preventing us
from using a Content-Security-Policy without ‘unsafe-eval’.
More details: Bitbucket Connect Library uses .eval(), preveting to use CSP without 'unsafe-inline' as required

2 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.