Hi folks!
First up, I have some good news. The deprecation period is actually six months for existing apps.
Unfortunately we buried the lede here, and this critical detail is hidden in an expand in the changelog entry. The wording in both the CDAC post and the changelog entry are not great, both in terms of the detail and empathy for our partners.
So to clarify, enforcement of requiring the READ scope for existing apps will not occur until January 5th, 2023. “Existing apps” here being defined as any app that was published on Marketplace on or before June 27th (the day the changelog entry was published).
We’ll get the formal comms updated to make sure this is more clearly spelt out.
My sincerest apologies for the confusing and scary-looking messaging here. We’re well aware of the pain platform change management and deprecations are currently causing partners. In the coming months we are planning to work on improving not just our communications, but the underlying processes behind how deprecations are carried out to make them more predictable, transparent, and empathetic to partners.
Also, thank you for all your feedback on the above! It’s great to see partners looking out for each other and highlighting concerns around impact to apps even when their own offerings are not impacted 
To address some of your specific concerns:
Unless there is an active exploit with a CVE number and customer communications that shit has hit the fan, it can wait at least a month…the matrix you use to determine the remediation window seems to lack any consideration for the impact on both vendors & customers. By the latter I don’t mean impact with regard to security, but with regard to the fact that they will experience outages due to vendors not being able to meet the deadline.
@remie First up—I fully agree. We absolutely need to better define how deprecation windows are determined and make this expectation transparent to partners. To shed a bit more light on why the process today is what it is: security is something Atlassian takes very seriously as a pillar of customer trust, and our security teams currently do not assess likelihood when raising vulnerabilities against internal Atlassian engineering teams. If a vulnerability has a remote chance of being exploited, it must be fixed within a tight SLA, no questions asked, without any consideration for roadmap impact. Atlassian has the resources to bake this into our engineering budgets. However it’s pretty clear that this same logic does not map well on to ecosystem, and it is unreasonable for partners to down tools and fix things that realistically present little or no actual risk to our mutual customers. Hence the varied enforcement in this deprecation for new apps versus existing apps — while the fact that the READ scope not being applied to the context being passed to certain extension points is clearly a gap in our security controls, it is vanishingly unlikely that existing partners are abusing this in a way that violates customer trust.
Totally agreed with this sentiment, either there are no apps out there that don’t use the read scope - in which case this announcement is probably unnecessary - or the change window is unacceptably short.
@ernst.stefan Our analysis does in fact show very limited impact on existing apps, but even in the case where there is (in theory) zero impact, we’re still aiming to standardise change messaging and deprecation processes in case our analysis is flawed. That said, I agree that the way this particular announcement was conveyed does unnecessarily cause concern and uncertainty, and we’ll evaluate how to improve future comms to make it a bit more obvious as to which changes may impact your existing apps.
Has anyone at atlassian reached out to the affected partners? When that is done - which contact is contacted and by who? Would love to get an understanding how atlassian performs these notices.
…
Is there a complete list of what will be blocked to take the guesswork out of this? Including on Confluence.
@danielwester @tobitheo though we have performed an impact analysis, but I can’t really publicly confirm whether apps are impacted or which apps are specifically impacted. That said, directly contacting impacted marketplace partners is something we do in certain circumstances relating to incidents and change management, and we’re evaluating how we make this a more consistent and reliable process in the future. Sorry for the vagaries here! Enumerating which apps may or may not be impacted by a vulnerability, even a low risk one, is not a great practice so we can’t really get specific on a public forum.
While I do echo what the other vendors have said, I would like to, again, also point out the insufficiency of Atlassian’s messaging towards admins when an update that requires manual intervention is available.
On one of our apps, we had rolled out this exact scope change (add READ scope where the app used to require NONE) last year in anticipation of making the app paid. Based on the roughly three months between the READ update and the paid update, it would take very long for all admins to approve the update.
…
This is a huge problem for us. We’ve even started to look at providing our own in-app messaging, which if each vendor does this, causes a very fragmented user experience.
@tobitheo @jeff great points, and the internal discussion around this deprecation has put some renewed focus on this issue. When determining the appropriate deprecation period for this change apps, we did a short analysis of scope changes (and more generally major version upgrades) and how customers responded to them. The results were mixed and require some deeper analysis, but there was enough concerning evidence to justify using the “standard” six month deprecation period (which @boris linked to) for existing apps instead of an expedited one, even though the root concern was a security vulnerability. Really the six months is a period for partners to update their apps and all of your customers to update to the new version (this fact should also have been highlighted in the comms).
@jeff we’ve raised a request with platform team to investigate how we might facilitate upgrades better at the platform level, but I’m afraid we don’t have a firm timeline on any improvements yet. I’m sure customer upgrade lag has implications for you all beyond security—revenue, app maintenance costs, user experience, etc—so I’d love to explore this topic in more detail with you both. Do you or @tobitheo (or anyone else reading this 
) have any data points, anecdotes, or past posts you’ve shared on this topic that I could read up on? Or if you’d be up for chatting directly, I’d be keen to set up a zoom (feel free to DM me if you like!)
cheers,
Tim Pettersen
Head of Developer Experience
) but perhaps we could have a “Discuss on the Developer Community” button on the Changelog so that we keep a single source of truth for changes but partners also have the opportunity to easily open a dialog.