CWE-400: Uncontrolled Resource Consumption

Hey guys o/ We are currently developing an app for Confluence cloud and during the development we stumbled across the following requirements regarding externally used libraries:

https://developer.atlassian.com/platform/marketplace/security-requirements-more-info/#use-of-external-components

No problem for us, so we added auditjs to our build stack and we are now scanning our dependencies and the dependencies of our dependencies. Unfortunately our scanner stumbled across a vulnerability which is as follows:

Vulnerability Title: CWE-400: Uncontrolled Resource Consumption (‘Resource Exhaustion’) (node-fetch)
ID: bcd8143c-e087-4471-b5ee-7537c8936296
Description: The software does not properly restrict the size or amount of resources that are requested or influenced by an actor, which can be used to consume more resources than intended.
CVSS Score: 7.5
CVSS Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
CVE: undefined
Reference: CWE-400: Uncontrolled Resource Consumption ('Resource Exhaustion') - Sonatype OSS Index

After tracking down the usage of the npm/node-fetch dependency, we found the following dependency chain: node-fetch → isomorphic-fetch → fbjs → styled-components → @atlaskit/banner, @atlaskit/form and other AtlasKit modules

So actually we can’t do anything regarding this vulnerability besides of acknowledging it and whitelisting it internally. You might ask yourself now “why is he here” :wink: My key message is basically for the team at Atlassian that maintains the AtlasKit to check for that vulnerability and maybe fix it by using the latest version of this dependency (just as you suggest us to do in the previously mentioned page: “We recommend that you use the latest stable version of any library to minimize the risk of exploitation.”).

If this thing is already fixed, just let me know and we will try to solve the issue on our end. That’s it :slight_smile: Over and out o/

No worries, they’ve already covered this in their policies!

And this one

https://community.developer.atlassian.com/t/reliance-on-atlassian-tooling-from-a-security-perspective/33611/6

1 Like

Finally had some time to read through some posts you pointed me at @remie Thank you very much for that :slight_smile: So to sum up: Compliance says “Don’t use libraries with critical / high security vulnerabilities” which means we cannot use AtlasKit modules. This topic was already addressed in the threads that you linked here, but Atlassians answer to that is whenever there is a security vulnerability it has to be fixed within the defined SLA’s, except it is a vulnerability caused by some of Atlassians components, right?

Just want to make sure that we can continue using our implementation as it currently is without the risk of being removed from the marketplace. This not making any sense at all from a customer / vendor point of view.

Atlassians answer to that is whenever there is a security vulnerability it has to be fixed within the defined SLA’s, except it is a vulnerability caused by some of Atlassians components, right?

Yes, this is an accurate summary. It get’s even weirder because in one of the threads they mentioned that they would be “lenient” towards vendors that cannot abide by the security policy because of issues unresolved by Atlassian. As if they are doing us a favour to let it slide.

I’m afraid this is a result of the hyper growth that Atlassian is experiencing, with several teams making real progress on maturing (like the security team) and other teams that are either understaffed or overwhelmed, or just took too much hay on their fork (like the design system team).

As with most things in the world right now, it is what it is. But at least you get to explain to your customers that you’re not at fault. And that if they are using Jira/Confluence/etc, they are using a vendor that does not comply to it’s own security policy.

1 Like