Having said that, I would love to see this community to find a way to create a solution (also approved by Atlassian) that will help all Marketplace Partners to implement an acceptable vulnerability scanner without having each partner re-inventing the wheel for their own app.
5 Likes
I see your point now. Thatās a very good explanation of the intention and makes total sense. Iāll work towards adding the requirement of running a vulnerability scanner. Thank you.
3 Likes
Can Atlassian please drop the Atlassian Security Scanner (I see what you did with the initials, a nice tribute to Atlassianās original name) and use Maven OWASP Dependency-Check instead, which is:
- Using the US governmentās NIST database,
- Open-source,
- Free,
- It works,
- It doesnāt count āprovidedā dependencies as critical vulnerabilities,
- It also scans the npm packages,
- It uses Maven, which the tool of the Atlassian SDK.
And as per OleksandrMetelytsia:
Atlassian scanner is not able to handle the whole variety of the edge cases
It is not an edge case to have āconfluence.jarā as a provided dependency when developing a Confluence plugin. It is the simplest case, and the Security Scanner. doesnāt handle it.
In other words, the Security Scanner is not suitable for its own job. Please drop it and use the industry standard instead, which as the added value of being open-source, standard, implementable by vendors, and moreover, free.
PS: Iāve seen your answer, awesome!
6 Likes
Weāll take a look at OWASP Dependency-Check more closely, thank you for sharing your experience.
Security scanner is able to filter out provided dependencies and scan npm packages if there is package.json found in the unpacked jar.
Edge cases that Iām talking about are, for example, apps which packed with not maven, e.g. when there is no pom.xml or package.json or similar files in the unpacked jar.
5 Likes
@OleksandrMetelytsia Can you please tell me what to do with this dependency. It is not provided but I use GSON to do some JSON parsing.
<dependency>
<groupId>com.google.code.gson</groupId>
<artifactId>gson</artifactId>
<version>2.2.2-atlassian-1</version>
</dependency>
What is the āsafeā alternative?
I am afraid to use the vanilla build.
I thought we have to use the special atlassian build since some bad OSGi stuff happens otherwise.
Can we use <provided> with this dependency too? I cannot remember, but in the past strange things happened when I used provided ā¦
Maybe Atlassian can clarify 
Hi @clouless. Let me check with the dev team about this gson dependency.
Hi @clouless. Please remove this dependency from your pom.xml file. Iāve raised an internal ticket to remove it from AMPS as well.
Hi @OleksandrMetelytsia thanks for the answer. I am using Gson in my code somewhere. Should I package my own vanilla version of GSON then instead?
Yes, if used, pls use the latest vanilla version.
1 Like
If the dependencies in package.json are also scanned, how will packages delivered by Atlassian be treated? I am asking in particular about Atlaskit packages.
The second question is how will it be possible to ignore the false positives results?
I think Iāve understood enough about this thread to answer those questions
-
Any upstream packages from Atlassian that have vulnerabilities will be ignored during the DC approval process. As a vendor, you are only responsible for maintaining 3rd party dependencies that are not from Atlassian packages or itās dependencies. Atlassian has created a proprietary scanner that will filter out these dependencies. They will run this as a sanity check to make sure that you have scanned your packages and resolved any vulnerabilities.
-
Unfortunately, Atlassian has decided not to make their proprietary solution to filter out false positives and provided packages (or itās dependencies) available to Atlassian Marketplace Partners. This means each partner will need to reinvent the wheel for themselves to create a workable solution.
3 Likes
Security Scanner has identified several high severity vulnerabilities in our dependencies (Ruby gem libraries). We have already identified them previously and due to version requirements of other dependencies are unable to upgrade their versions. In those cases, we evaluate if the identified vulnerability can be exploited in our context. If yes then we create a patch for that library to avoid exploitation of it in our app.
Can we provide a list of vulnerabilities that should be ignored with our description of why they cannot be exploited in our context or when we have patched these dependencies? As I see it is possible to provide .snyk YAML files for the snyk CLI tool where it is possible to specify which vulnerabilities should be ignored. Could we provide such .snyk files for the Security Scanner?
Kind regards,
Raimonds
Thank you very much for all the feedback on this post. The sheer size of it indicates how important this process is for you. Weāve identified two major concerns in this feedback:
- The tooling that Atlassian suggested is insufficient as it provides different scan results than tooling which Atlassian uses internally to validate apps.
- Approval Process requirements after Feb 2022 need to be rephrased to clarify the expectations and address non-obvious scenarios.
We are working to address those points, and we will provide an update by December 17th. Please stay tuned!
5 Likes
Hi @clouless,
I wanted to add more detail to @OleksandrMetelytsiaās answer.
The meaning of <provided> scope in your pom.xml file is that the dependency will not be bundled with your artifact, and in runtime your app will use packages exported by the host product. If your app is using gson and the product also provides gson then it makes sense to use <provided> as it will make your app lighter and will reduce the memory footprint on the running system. In such case you want to make sure youāre using the same version of gson as the product.
The alternative is the compile scope which should be used for dependencies not exported by the host product or for scenarios where the version of the dependency you rely on is radically different than the one the product exports.
2 Likes
Thank you for listing to our feedback. May I provide you with yet another suggestion?
It would be great if Atlassian would seek our guidance prior to making announcements to these programs. There are several recent examples in which Atlassian made an announcements only to adjust them based on the Atlassian Marketplace Partners pushing back.
We have a lot of experience which you can use to your advantage and it would help in terms of mutual understanding and improve the relationship between Atlassian and Marketplace Partners if you would implement a process of RfCās to get input.
12 Likes
Thanks for this suggestion @remie.
Hi @kbrazulewicz thanks for clarification. I already new about that in theory but good to hear it again
I had such a case for Guava dependency and CharMatcher.INVISIBLE which was deprecated and removed in some version of the jar. Making my app break on newer versions of Jira.
Just to 1000% clarify, would I bundle my own GSON I would do:
(1) specify as compile dependency
<dependency>
<groupId>com.google.code.gson</groupId>
<artifactId>gson</artifactId>
<version>2.8.9</version>
<scope>compile</scope>
</dependency>
(2) Disallow the import in jira-maven-plugins <Import-Package>
...
<build>
<plugins>
<plugin>
<groupId>com.atlassian.maven.plugins</groupId>
<artifactId>jira-maven-plugin</artifactId>
...
<configuration>
...
<instructions>
<Import-Package>
com.atlassian.sal.*,
!com.google.gson.*
</Import-Package>
At least that is what I read in the docs somewhere
Hi @clouless. Could you pls redirect this question to CDAC or Atlassian support, as the configuration of jira-maven-plugins is not an area of expertise for the DC apps tooling team.
1 Like