@danielwester ,
AMS tickets are visible only for Atlassian Staff that have permissions as per internal policy.
2 Likes
Hello @OleksandrKravchenko,
I see that youâve responded to several comments by saying âAMS tickets will be visible only for security contacts in your Partners profile on the marketplaceâ.
Let me make an official feature request here. I am sure many others will like this as well.
We assign different vulnerabilities to different people. We need the ability to share AMS tickets with other users in our company who are not marked as Security Contacts.
3 Likes
@OleksandrKravchenko / @kbrazulewicz / @OleksandrMetelytsia,
I just received a bunch of emails about this upcoming change, so I guess youâre still moving forward with this even though you have not responded to community concerns (incl. my comment).
CC: @tpettersen / @Miro.Capka
Hi @remie. There is no any change of course. Still, any scanner could be used and encouraged to do so. Atlassian does not dictate which scanner to use.
Check from our side is complimentary and intended to catch cases when no scanning exists at all from app partnersâ side. E.g. in between annual reviews new critical vulnerability was identified and app partner does not have a process to detect this for whatever reason.
2 Likes
Hi @OleksandrMetelytsia ,
Ok, letâs go over this, as apparently linking to the original thread was not good enough.
On Novâ21, @kbrazulewicz posted an announcement about a change to the Data Center Approval process. In short, it boiled down to this:
What is changing?
We are extending the Data Center App Approval process and introducing a third party security scanner for all Data Center apps.
The change also included this lovely snippet:
Starting from April 2022, weâll track vulnerabilities in the Atlassian Marketplace Security Jira project
Now obviously, April 2022 is long gone and this did not happen. That is also because of the lengthy discussion we had in the thread, leading to the following three updates:
Update (Dec 8th)
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!
Update (Dec 17th)
For the last week, we have been testing alternative scanner solutions and discussing legal aspects of those approaches. We are not yet satisfied with the outcomes thus we will continue the investigation in the tooling area.
At the same time, we are drafting updates to the Approval Process documentation published on developers.atlassian.com .
Given the upcoming holiday period, we will provide another update by January 14th.Update (Jan 14th)
Thank you very much for your patience. For the last few weeks, we were validating available scanner solutions and came up with updates to the Approval Process documentation.
We clarified that during the Approval Process, you need to provide a scan report free of critical- and high-severity vulnerabilities in the libraries bundled with your app. You can also choose a Software Composition Analysis tool of your choice to create this report.
For more details please see Security Scanner for DC Apps documentation .
In these updates, as you can see, the original plan changed from âWe will be running our own scannerâ to âyou need to provide proof of vulnerability scanningâ.
In addition, the plan to start doing periodic scanning as per April 2022 was also dropped (or at least, it was never mentioned again).
Now out of the blue, one year later, @OleksandrKravchenko posts a renewed change to the Data Center App Security process that somehow reinstates both the custom scanner solution as well as the periodic scanning by Atlassian and creation of tickets in the AMS Jira project.
So between January 14th, 2022 and now, something has changed.
Iâm going to ask again: what has changed from Atlassian perspective between January 2022 and June 2023, why did it Atlassian change position, and why is it that Atlassian did not seek any advise from the community prior to changing position knowing that there has been a lengthy discussion (spanning 3 months) about this same topic.
Itâs getting really tiresome to have to repeat this question 3 times already.
Atlassian, stop bullshitting.
CC: @tpettersen / @Miro.Capka
8 Likes
Another thing Iâm curious about.
If Atlassian scans for vulnerabilities, is there a way to suppress certain vulnerabilities in 3rd party libraries? We have a few libraries with vunerabilties which are unlikly to be ever fixed, but also do not affect the app. Mostly because the code path / environment for the vulnerability in the 3rd party library does apply in our app.
1 Like
hi @RomanStoffel . Yes, there is a possibility to suppress certain vulnerabilities if you provide an explanation and evidence that a particular vulnerability is not exploitable for your app. This would be done case by case in AMS tickets.
3 Likes
Hi,
It will really help us if we could have a proactive approach and anticipate those vulnerability corrections by using our own scanners and planning our own time to correct the vulnerabilities. Reacting to the scanning results done by Atlassianâs scanner tool which can generate different results is going to be very time consuming and complex for a smaller vendors.
Could we please avoid that? Could you let us know which tools / scanners are acceptable for you or which standards could we use to be sure that the results will not differ?
Thanks
1 Like
@OleksandrMetelytsia / @kbrazulewicz / @OleksandrKravchenko,
Would be great to get a response. This is only the 5th time Iâm asking this, and Iâm pretty sure that is my lucky number!
Cheers,
Remie
cc: @tpettersen / @Miro.Capka / @ibuchanan
Iâll follow up internally and ensure the relevant teams are aware of your question, and see whether theyâre able to provide any further information publicly at this time.
1 Like
hi @dusan.spaic
Our ask is to use any scanner of your choice for proactive testing, e.g. Snyk, Owasp dependency check, Grype, etc. All scanners work pretty well when there is a source code and a dependency tree is available. Also, we do not want to dictate which scanner to use.
Internally we use the same tools (which look to open NVD and GitHub Advisory vulnerability databases) but added some extra logic as for us only .jar files are available(but not source code), which leads to a lot of false positives which have to be properly handled.
Atlassian scannersâ aim is to detect cases when there is no scanning at all.
Regarding the difference between different scanners, e.g. we made a comparison with snyk results and identified only 5 cases from all Marketplace DC apps.
So in 99% of cases, snyk/owasp/grype will find the same or even more real vulnerabilities than Atlassian scanner. Our main goal is to identify cases when there is no regular/proactive scanning from app parterâs side and highlight critical/high vulnerabilities as soon as possible. Also, for DC apps vulnerabilities timeframe for resolution is 12 weeks (extension policy described here)
Thanks
4 Likes
Thanks @ibuchanan, and apologies community itâs taken a while for us to respond. We are working through your feedback and we do want to address your concerns. We will have a full response and answers to your concerns by Wednesday July 5th.
We will also delay the start of the program and provide the new date in the update.
5 Likes
Hi,
Iâm Krystian Brazulewicz, Engineering Manager in the DC Core team at Atlassian
We have worked through your feedback and we wanted to address your most frequent questions.
In February 2022 we introduced a new security requirement for all apps submitted for Data Center App Approval. Apps need to be free from critical- and high-severity security vulnerabilities in third-party dependencies. Partners are obliged to provide the vulnerability scan reports that confirm that. Atlassian is validating those reports using 3rd party security scanner.
Since the kickoff of the project, we were able to significantly reduce the number of vulnerabilities present in the DC Apps available on Atlassian Marketplace. This is a success for our customers who are safer than they used to be. This is a success we owe you and your diligence.
The change to the annual DC App Approval process gave us an improvement but it still doesnât provide the alignment with the timeframes defined in Security Bug Fix Policy for Marketplace apps. New security issues can be discovered every day and itâs critical to address vulnerabilities as soon as possible to ensure our customers can continuously trust the Atlassian Ecosystem. This is our shared commitment to customers and the rollout of the security scanner for DC Apps improves our ability to act on the newly discovered vulnerabilities in a more agile way. We believe this will improve the security posture of DC Apps even further and will also provide a more convenient way to track security issues for Partners.
What is the date of the rollout of the integration?
We will start the gradual rollout of tracking Data Center app vulnerabilities in the Atlassian Marketplace Security in mid-August 2023.
How does this announcement relate to the one from November 2021?
In the announcement in November 2021, we notified you about the addition of security requirement to the DC App Approval process which went live in February 2022. At that time we planned to roll out the integration with Atlassian Marketplace Security in April 2022. The global situation forced us to postpone going live with this integration but internally we were using it to validate the security reports submitted during the annual DC App Approval process.
Can Atlassian make the vulnerability scanner publicly available?
Atlassian is using a 3rd party solution to identify the vulnerabilities in the open-source libraries. At the moment we are not in the position to endorse any specific solution on the market, nor do we have the technical means to make the vulnerability scanner infrastructure publicly available. Please refer to the Security Scanner for Data Center apps for the available options.
A significant part of your feedback revolved around enabling Partners to use a solution that would guarantee exactly the same scan results. We will reevaluate our technical and legal options in this area and provide an update before the end of September.
We also validated the differences in detected critical- and high-severity vulnerabilities across different tools. Our data shows that differences are marginal (2%) and in those unlikely cases, weâd like to hear from you and resolve the issue.
Is Atlassian changing the policy?
The responsibilities and timelines in the Security Bug Fix Policy for Marketplace apps remain the same. What we are changing is the process of how and how often we inform Partners about the risk of them breaking this policy.
Which dependencies are scanned?
We are only scanning the 3rd party libraries which are bundled with the app. None of the dependencies in the provided scope dependencies are scanned as these are not bundled with the app.
Please refer to Security Scanner for Data Center apps for more technical details.
Suppressing certain vulnerabilities.
We are using this option to exclude confirmed false positives from the report. We are open to discuss your concerns about specific vulnerabilities on a case-by-case basis in your AMS ticket.
Please refer to Security Scanner for Data Center apps for more technical details.
7 Likes
It would be insanity for them to go through all that hassle to maintain a public version of the scanner while you could likely accomplish the same thing with any other scanner: https://developer.atlassian.com/platform/marketplace/dc-apps-security-scanner/
RTFM
It is possible.
You can analyze it before submitting the app for approval. There are several tools you can use listed there.
If we could accomplish the same thing with any other scanner, why would Atlassian have to create a proprietary solution? Your answer makes no sense.
The point we are trying to make is that apparently there is a reason for Atlassian to NOT use any of the available scanners, which could lead to differences in results between our scanners and theirs. Which is why, if apparently Atlassian feels it is required to create a separate scanner, we would like to have access to this in order to make sure that our results match theirs.
That is not a weird request to make, especially from a 40+ billion dollar company who already has made loads of open source tooling available to Atlassian developers.
They probably are using something available on the market, maybe even something that is a commercial solution tailored to their needs, integrated into their existing infrastructure, and that they are paying for.
As a matter of fact,
âAtlassian is using a 3rd party solution to identify the vulnerabilitiesâ
This means itâs not their proprietary solution (not their intellectual property, or not something they built and can simply make publicly available).
They could at least tell us what they are using, or who they contracted to do that for them, but that would not be a good thing. Then everyone could go to the same software supplier/contractor, and could directly influence the results.
Or they could be obliged by an NDA to not share that information.
Either way, I doubt itâs anything more than a simple SCA that connects to the CVE catalog.
Remember, these vulnerabilities are publicly available and Atlassian canât just simply pull a sneaky on you with some vulnerability no oneâs ever heard of (unless itâs something thatâs in their code and they are, naturally, the first ones to discover them).
The scanner Atlassian uses is not made for us to send them an app and for them to give us results; the process in place is just so Atlassian can tell us, âHey, your app has these vulnerabilities; ideally, youâd submit an app without vulnerabilities so it doesnât come to this, but if you donât know how we have a few documentation pages where we can teach youâ.
@tayicknay Iâm well aware of the status of their scanner solution, but youâre missing the point.
This is not a matter of bad faith: Marketplace Partners also want their apps to be secure and to detect vulnerabilities as early as possible.
There is a reason why Atlassian is not using out-of-the-box solutions, because their infrastructure requires a tailored process. For instance because of the many âprovidedâ dependencies. Which means that each Marketplace Partners will be re-inventing the wheel tweaking the available scanner solutions to come up with a decent report that only outputs vulnerabilities for which the vendor is responsible.
As we do not know what Atlassian has done, this means that we can still tweak it wrongly and get different results compared to Atlassian. Which means having to do a back & forth with Atlassian support, which costs time & effort for all parties involved.
Being able to run Atlassian scanner will A) spare each Marketplace Partner of reinventing the wheel and B) prevent time wasted on reconciliation.
7 Likes