Stop saying forge is more secure than connect

Forge
, ,
1

It has become a popular catch phrase amongst Atlassian staff to say that Forge is more secure than Connect, and that his is a reason why developers should move to Forge.

I know this is part of the trust signal campaign to improve customer confidence in the Atlassian Ecosystem, but in reality this is really just backfiring spectacularly.

The side-effect of this communication is that you are implying that Connect, the framework on which all major apps are currently still running, is insecure. This is simply not true and it is hurting customer trust in the current apps as well as undermining the efforts by Atlassian Marketplace Partners to ensuring safe & reliable operations. You are making us all look bad for no reason.

Secondly, the statement is also simply not true. Forge is not more secure than Connect per definition. Sure, Connect can improve with regard to security, but a lot of security features that are native to Forge could also have been implemented for Connect. Atlassian chose not to invest in Connect and re-build from scratch. That does not make Connect inherently less secure than Forge.

The only real difference between Connect and Forge is that Forge apps run on Atlassian maintained infrastructure. But that only applies to the part of the shared responsibility model that Atlassian is responsible for, and it also does not mean that Marketplace Partners would not be able to achieve similar security on their own platforms. You are again undermining the efforts from Atlassian Marketplace Partners by implying that we are not capable of running our apps securely on our own infrastructure.

I would really like for Atlassian to stop perpetuating this falsehood and deliberately creating doubt with regard to the security of Connect just to push your Forge agenda. Especially because Forge is not at all ready to support large & complex apps making it impossible for many vendors to migrate.

35 Likes
2

@remie,

In full acknowledgement that we have said that, could you point where that assertion has most impact on customers? To fully consider your case, I would like to understand some concrete examples where Atlassian messaging is working against our mutual goals.

2 Likes
3

@ibuchanan I haven’t kept track of all the discussions on CDAC or CAC, and the search feature does not really make it intuitive to find any occurrences. But even in the official documentation, it is riddled with the “forge is (more) secure” message. It stops short at saying Connect is insecure, but it is hard to ignore the (incorrect) messaging.

It is clear that “security” is a selling point of Forge for Atlassian, but as mentioned above, I personally think this comes at a high price as it is detrimental to the current ecosystem and also unfair given that most of the reason why Forge is “more” secure is because Atlassian chose not to invest in equal security for Connect.

BTW, the one instance I can share (and the trigger for this message) is this one: https://community.developer.atlassian.com/t/forge-app-deployment-impossible-due-to-new-undocumented-scope-limit/58564/7

1 Like
4

In the blog post Unifying Atlassian Connect and Forge: An Update - Atlassian Developer Blog

In State 2, the app gains important security benefits. First, an app developer can limit the types of data the app can access using scopes, bringing the app in line with the principle of least privilege. Second, replacing Connect remote iframes protects app users from common remote iframe browser-based vulnerabilities and domain hijacking.

Because these security improvements are high priority, we will be requiring all Connect apps to reach State 2, and in the future, Connect will stop supporting JWT auth and remote iframes. While these services are not being deprecated yet and we are still far out from making this a hard requirement, we encourage app developers to start planning to make these changes as soon as development is unblocked, which we estimate will happen towards the end of 2022.

So this implies that Connect remote iframes are not as secure as Forge UI. There was already a lot of negative feedback about this blog post in CDAC 22 Sep 2021 - Unifying Atlassian Connect and Forge: An Update - #60 by jhazelwood

2 Likes
5

Hi @remie, PMM for developer platform here :wave:. I work on messaging and positioning for Forge.

We do believe security is a core value pillar of Forge. However, it is not our intent to imply that apps built on Connect are not secure. There are apps available in the Marketplace today, built on Connect, that meet very high security standards. Partners are quite capable of building secure apps on Connect, as you rightly point out.

We think Forge provides value for developers who are looking to meet this same security standard, but with lower effort. Security is still a shared responsibility on Forge, but hosting apps on Atlassian infrastructure allows us to offer some security benefits that developers would have to build themselves on Connect. These include the ability to tightly manage data egress, secure storage, and protection from some common vulnerabilities.

When it comes to customer confidence in the Ecosystem, we do not want to oversimplify by equating security with a single framework or platform. I’ll let my counterparts on the product side chime in with more details about how we’re thinking about this.

We know perceptions of Connect security have an impact on partners. We want to get the solution right - not just in the product but in the way we talk about it too.

8 Likes
6

@kwhite thank you for your quick & considered response!

I would really love for Atlassian documentation & forge-related communications to have this as the main message. It is possible to create a secure app on both platforms, with Forge including many security best-practices out of the box and Connect by leveraging several security programs (highlighted with badges) to indicate which partners have achieved similar levels of security standards.

This way, security is not a subject either omitted with Connect or made obscure by saying it is the sole responsibility of the vendor. Because Atlassian has spent a lot of effort in trust signalling for Connect using the programs & badges. It is a shame not to mention those in documentation and/or comparison with Forge.

Personally, I’m still not happy with Atlassian using security as a selling point for Forge because I don’t think it is fair, but a more balanced messaging would already be a great improvement.

14 Likes
7

Most of the security concerns could be eliminated, if Atlassian would provide:

  1. Storage API for Connect
  2. option to host/run Connect apps in AWS infrastructure, controlled by Atlassian

That would be much easier to implement and would work thousands times better.

11 Likes
8

@ibuchanan you asked for more examples. I think this thread is important: App storage (aka content of Storage API) not included in site backup? - #6 by danielwester

If the overall messaging of Atlassian regarding forge is that it is production ready and that it is more secure & reliable compared to Connect, it is weird that A) a critical feature like Forge Storage API is still in experimental phase and B) that App data stored in Forge Storage API is not part of the backup & restore procedure.

You are selling a story of a robust, secure & reliable service even though that service does not meet even the most basic standard of having backup & restore.

4 Likes
9

Hi, @remie . You may already know me, but my name is Jake and I am the Product Manager for Ecosystem Security.

Firstly, thank you for taking the time to raise your concerns about the way we message and position Forge. As Karen mentioned earlier, “we do believe security is a core value pillar of Forge. However, it is not our intent to imply that apps built on Connect are not secure.” We want to get this messaging right and we believe we need your help.

Today, we provide you with limited capabilities to articulate your own trust posture to customers on Atlassian Marketplace. As a result, customers struggle to understand which apps meet their security requirements leading to lengthy sales cycles and lost cloud sales opportunities. We are working to provide greater transparency to customers by providing you with more opportunity to surface relevant information pertaining to security / privacy / compliance, etc. This effort is platform agnostic.

We believe Forge can eventually help Marketplace Partners who don’t have the time or resources to achieve and maintain enterprise-grade security on their own platforms. As you know, security requires constant investment to keep up with evolving standards.

In the meantime, our goal is to uplift the security posture of all apps in the Marketplace and give enterprise customers confidence that apps are enterprise-ready in cloud. We are looking into additional improvements we can make across platforms and product to help apps – whether they are built on Connect or Forge – meet the needs of our customers in the cloud.

This will be a long-term effort - uplifting app security and providing transparency for customers will be ongoing over a long period of time. We want to better understand challenges you’re seeing with customer perception of Connect so we can make sure our solutions address them.

5 Likes
10

Just in case you don’t know and it might give some inspiration
This is what Microsoft provides for the apps in Teams and how our app looks like:

Basically they provide a questionnaire vendors can fill out in regards to different topics:
Security, Privacy, Compliance and they publish it in their docs.

1 Like
11

We deal with a considerable volume of security information requests regarding our connect implementation. This topic does come up, certainly every time we’re talking to a bank. I’ll quote one of the tickets on the subject:

Atlassian confirmed that App data will only be guaranteed to reside within the AWS realm of the Atlassian Cloud subscription if the App is developed with the Atlassian Forge framework. We are now asking all App vendors when they will release a Forge version of their app.

I understand the need for clarity to this kind of user and the comment is technically accurate, but the forge implementation of Confluence (Jira is better) was nowhere near ready when the comment was made (November 2021) and I cannot see any substantial progress since then on Confluence forge.

If this vendor were to come back in November 2022, ask if we have a forge implementation and we answer that it’s still nowhere close to being ready, they would either think:

  • Why is Atlassian telling us to go to cloud and that we should ask all third-party vendors to move to forge and then not developing forge to the extent needed?

  • This vendor is lying and probably just too lazy to implement it.

We (Atlassian and us) just don’t sound joined up over this and at the current rate I can’t see the platform being ready before at least 2025. Can’t Atlassian just admit (privately) that forge isn’t ready and they should plan to stay on DC for the next 2-3 years at a minimum if they use apps?

In the meantime we’re move than happy to work with Atlassian to migrate to forge, constructively, in private, so that when these users are told it’s a good time to move to cloud, it really is.

9 Likes
12

@JakeComito Why was the CAIQ Lite survey dropped? It provided 99% of the answers to questions we get asked. We still update it internally and provide it to customers when they ask about security.

My experiences are similar to @daviddrawio. When you get a quote about what Atlassian is saying about forge to customers to try and get them to move onto cloud it can raise some awkward questions. If it’s big customer you spend the time with them and show them the public documentation for forge and what can be done with it they get very surprised Atlassian is pushing it. I doubt this is great for trust building.

I second that it has been internally acknowledged that Forge isn’t ready and shouldn’t be pushed for a couple of years.

7 Likes
13

If security for Forge is so important, I do not understand why it is not possible to give access to a Forge app to multiple developers. Currently, if multiple people are working on a Forge app, they need to share the Forge credentials.
Shared credentials are not regarded as security best practice.

4 Likes
14

Hi, @JakeComito !

Adding my 5 cents to what was already mentioned above:

  1. Could you please share some stats on how many sales have dropped because of Connect?

  2. Was there at least a single significant security incident caused by Partner? I believe there hardly was any, and if I’m right, it would be nice to see Atlassian talking about this instead of Forge.

  3. Why adding secure storage to Connect API was never an option for Atlassian to make Connect apps safer for customers?

  4. Why aren’t Self-Assessment, Cloud Fortified, Bug Bounty & CAIQ-Lite just enough? I mean, seriously - why the heck do we spend our time complying with all those requirements if they are just not working? Has anyone in Atlassian ever thought about calculating the cost for a Partner to constantly jump through these hoops?

  5. Why is the link to the Security Policy right on the app’s page not transparent enough? What makes you think we as partners have “limited capabilities to articulate our trust posture?” E.g. at Colined we had never had an issue with customers regarding our [security policy] (Colined Cloud Security and Privacy Policy for Atlassian Marketplace | Colined Legal). Worst case scenario is filling in a custom questionnaire, created inside the company. Again, it was never a problem.

  6. Do you understand that we as Partners have already been pushed to Connect, and now all of a sudden, we need to redo everything to a half-baked Forge. And there no (zero, none, doesn’t exist) guarantee that Atlassians won’t come with yet another brilliant idea about most safe/secure/effective/etc. framework we must use in about a year or two from now.

This being said, I have no doubt there won’t be any tangible answers. This is just another comment to support fellow partners.

1 Like
15

I think the thread is a little in danger of disappearing in details that will kill the issue by analysis.

Atlassian isn’t wrong with the high level idea of what they are trying to implement. We’ve had discussions with some huge companies (outside of the Atlassian eco) about custom implementations and how to assure that data doesn’t leak out. These users want a setup that proves data cannot exfiltrate from the browser or back-end servers.

On the browser that comes mostly down to a correctly constructed CSP.

On the backend that means either a deny-by-default API that only opens up certain functionality (roughly what forge is), or a sandboxed environment.

What @dmitry.astapkovich said “option to host/run Connect apps in AWS infrastructure, controlled by Atlassian” is something I’ve been wondering for some time myself. Is it possible that forge is over-reaching by trying to define an API?

I know a change of direction would be heavy at this stage, but can’t this be done with a specifically controlled private subnet on AWS and a CSP? There would need to be some amount of auditing of things like gateways and it would need to be delivered on an atlassian domain, but it seems easier than trying to build forge, which I think everyone involved has realised is a massive task and needs a far larger team than is currently available.

I’m sure I’m over simplifying, but was this analysed as a possible option and, if yes, what were the technical arguments against?

1 Like
16

Hi @JakeComito,

Thank you for taking the time for such an elaborate response, and for being open to the feedback from the Atlassian Marketplace Partner community.

I’m afraid that by limiting your question to our current interactions with customers you are somewhat sidestepping from the issue. I’m grateful for responses from @daviddrawio and @alan.parkinson as they have more experience with Enterprise customers.

Although we are only a small vendor, due to the nature of some of our apps we have several customers I would consider Enterprise (Fortune500 companies, most of the top 5 largest arms dealers, military surveillance, several of the largest telco’s in the US, etc). None of these companies have ever asked us to do a security questionnaire for our products. The only communication we receive from them is to opt-out from our EULA clause that allows us to use their name/logo. Even our largest Connect customers, with 10.000+ users, has never asked us to fill in a security questionnaire.

The only time a security questionnaire request has resulted in a customer not converting has been because we declined to invest time in filing out their custom form because of the fact that they were too small a prospect (it was a small healthcare startup that had regulatory requirements).

This is why, for me, the whole “security” discussion is alienating, because I never consider it as a blocking issue that prevents me from growing my business. Now obviously, I don’t know what I don’t know, right? I don’t know whether or not I’m missing out on business because of customers’ security concerns with Connect. If they do not contact us, do not start an evaluation, do not respond to our drip-mail campaign, I don’t know how big the issue is that I’m facing.

What I do know is that I am pleased with the conversion rate of our business. With how our business has grown over the past years. There is no reason for me to be concerned over this as I’m happy with our business operations. In that sense, our business’ interest are not aligned with Atlassian with regard to Forge and the future of Connect. We are happy with Connect and currently do not consider Connect to be an impediment to our business.

Now obviously, we are not exemplary to the entire ecosystem, and i fully recognize that mileage may vary per partner. But to us, migrating to forge is solely a cost, and there are no clear benefits. We’re only doing this because atlassian expects us to do so. Which is also why we will not be early adaptors and will wait for the dust to settle.

Nonetheless, I would like to argue that focussing on these practical examples will draw us away from the overarching point that I feel is worth discussing, which also was raised by both @daviddrawio and @alan.parkinson.

That is the issue of Forge being sold as GA and a worthy replacement of Connect, that the messaging from Atlassian towards customers is to signal that vendors are expected to be migrating to Forge and that customers should encourage this from vendors, even though both Atlassian and the Atlassian Marketplace Partners are fully aware that technically Forge is nowhere near that stage.

Even though for me, for my business, Forge is a nuisance and we do not consider it a requirement to succeed, I’m fine with eventually following Atlassian down that path. But the way this is currently transpiring is sub-optimal at best, and harmful at worst.

1 Like
17

While it sounds like a good thing, this means that now a very large amount of people will spend alot of time and resources (which might be used in a more productive manner) to forceful migration of their apps to a new platform, which is nowhere any near being feature-complete even in comparison to Connect.

18

Hi, Atlassian engineer here, working on Connect-on-Forge / Connect-to-Forge migrations, etc. and also speaking on a related topic at Developer Day on Thursday.

You may remember me from 22 Sep 2021 - Unifying Atlassian Connect and Forge: An Update - just wanted to add my thanks to all participants for sharing your frank feedback and insights on the positioning of Connect and Forge with regard to trust and security - lots of food for thought for our team, here.

9 Likes
19

Thank you @BalaVenkatrao for the nuanced messaging regarding Forge & Connect, and highlighting the efforts that the Marketplace Partner community together with Atlassian has already put into establishing trust in the Atlassian Ecosystem. I really enjoyed reading Working Together to Build Trust in our Cloud Ecosystem - Atlassian Developer Blog

7 Likes