How does this work? Will Atlassian provide us with an overview of the amount of customers per region and show where we lack coverage?
The Atlassian security team has taken the direction of migrating partners Bug bounty programs to public to increase security engagement and visibility. We explored alternative options such an enforcing activity metrics on private programs, these options could work but they’d increase operational overhead for partners as well as lead to gamification of metrics to pass the bar.
Atlassian has operated a public bug bounty program for years and has dedicated subject matter experts in this domain, we’d be applying these learnings of operating a large scale program to the marketplace programs. Fun fact, we’re one of the most active Bug Bounty’s on BugCrowd (including partners like you).
While it’s clear there’s potential noise from AI submissions, we’re defining stricter acceptance criteria for reports as well as tightening program scopes with BugCrowd to avoid scanner type noise, AI generated findings and reward higher quality findings from researchers.
One big caveat to note for Bug bounty: the number of security researchers that understand the Atlassian Cloud is a smaller subset of people, narrowing this down to Forge and marketplace is an even smaller audience. We do expect some increased activity but nothing exponential by switching programs to public.
If this decision leads to unmanageable volume for the majority of partners, we’re always open to reassess the change and work with BugCrowd to control the volume.
Thanks, @remie, I had barely pressed send on my response to @raimonds.simanovskis before you replied… lightning fast! 
How does this work? Will Atlassian provide us with an overview of the amount of customers per region and show where we lack coverage?
I acknowledge the gap in understanding where your customers are based, but the vast majority of customers are based in the US or EU regions. We are, however, not going to mandate that you support these regions, as this is a business decision you need to make.
There are also other regions that Atlassian supports, and you may get customers asking for you to support these regions, but this is an individual business decision that would need to be made.
Hey Ryan, thank you for your comprehensive feedback! It is very much appreciated.
We support the move to simplify and consolidate Marketplace trust programs to provide clearer, more meaningful signals to current and prospective customers. Reducing overlapping badges is a positive step toward making trust easier to understand and evaluate.
Thank you, I am glad we are heading in the right direction.
We’d strongly encourage future communication of A4A — to both partners and customers — to be explicit about its broader intent upfront, positioning it as a holistic app quality and operational excellence standard.
Great feedback, and I will ensure future comms are clearer about the program’s broader scope 
Many of the proposed A4A requirements are reasonable in intent but are currently described using vague or subjective language (for example, “consumes APIs efficiently”). For a program of this importance, requirements need to be precise, measurable, and consistently verifiable.
This has been a recurring theme in the feedback on this RFC, and I completely agree. The A4A requirements should be verifiable and measurable. Once this RFC closes, we will go back through the list of requirements and evaluate which can be objectively validated.
I really liked how @AaronMorris1 expressed this in his response above:
“Customers expect trust signals to be objective. That’s why SOC 2 is one of the strongest trust signals. Presenting objective criteria is the #1 way to create strong trust signals.”
We’d appreciate some clarification on whether the requirements defined for the new Atlassian-provided penetration testing program are intended to be sufficient for use as evidence in SOC2 compliance assessments.
For partners maintaining SOC2 certification, penetration testing is a recurring compliance requirement. If the scope or outputs of this program do not meet auditor expectations, partners may still need to commission additional third-party testing, resulting in duplicated effort and increased cost with limited additional security benefit.
We understand the need for SOC2 overlap to avoid duplication. Our pentesting requirements are that you use a CREST-accredited vendor or utilise the BugCrowd-managed program, and that testing occurred within the past year. Beyond that, the process is flexible to your needs and can be enhanced to meet other requirements, such as SOC2.
Partners can submit special requests to Bugcrowd when applying for Pentesting through our paved path, specifying additional scope and output details.
Requirement 4.2 — “App supports Data Residency (pinning and migration)”
The requirement does not currently specify a minimum expectation for the number of realms that remote data stores must support.As written, it’s unclear whether existing realm coverage is sufficient or whether additional regional investment is expected. Clear guidance on what constitutes adequate coverage at launch (and how this may evolve) would help partners assess gaps and plan investment with confidence.
We will not mandate which regions you support, but you should support data residency in the regions where your customers are and include data migration support between them.
Requirement 7.2 — “Uses Forge LLMs where practical”
As written, it’s unclear who determines what is considered practical, or what process will be used to assess or validate this.
Based on other similar feedback re: the timing of Forge LLMs (considering they are still in EAP), we are proposing to update this requirement to be something along the lines of:
“Uses Forge LLMs or has publicly documented Responsible AI policies and controls that they can link to.”
Does this help?
We support the direction of this proposal and appreciate the effort to simplify trust signals while raising the bar for Marketplace apps. The feedback above is intended to help ensure A4A is clear, achievable, and consistently applied, particularly given the investment some requirements may entail.
We very much appreciate the time you took to provide this feedback. It will certainly help as we continue to refine the A4A requirements. Thanks.
Hi again @marc,
I fully agree there’s room for improvement in our rate limits. However I’d also be keen to explore smaller tactical steps we can take to improve resiliency.
Would you mind elaborating a little more on your Forge macro export example? I’m under the impression they’re essentially backend functions that export ADF, as in this example. I was thinking we could enhance the contract for adfExport functions to allow it to throw an InvocationError to signal to the export process that it has been rate limited.
cheers,
Tim
We have the same scenario as @marc, where our customers have multiple instances of a macro per page. In bulk exports, that one customer can trigger Atlassian to generate thousands of macro render requests. Each macro requires site config, page data and properties to render. Without caching this is expensive in rest api calls.
The invocation error you mentioned has a retry after (max 15 minutes) as a return value. Maybe if the retry after period matched the global rate limiter retry period (60 min) the invokeError could work?
Although out of scope for this RFC, that it is possible for an app to be locked out globally for 60 minutes when 1 customer exports a large set of Confluence page highlights a problem with overall system reliability. That would fail the A4A reliability requirement, right?
Hey @clouless, thanks for your thoughtful feedback. We really appreciate it.
1.1 pen testing => is not the bug bounty program with bug crowd enough testing? This will introduce yearly costs per app that are very high. Smaller apps will no longer be able to uphold cloud security programs with such high costs.
The Bug Bounty program alone doesn’t guarantee continued security assurance. The Atlassian security team conducted internal penetration tests across ~100 apps with low bug bounty activity, uncovering critical & high vulnerabilities in participating apps.
These tests showed the value in creating a partner-facing penetration testing program to provide a second layer of security assurance for partners and customers. Penetration Testing also ranked higher priority than Bug Bounty under procurement criteria through our customer surveys. The A4A program specifically targets Enterprise customers with higher needs.
We understand there are increased costs for completing Penetration Tests, which can be cost-prohibitive across a large number of apps. Program participation is optional for partners and is only required as part of A4A. If it’s not feasible to enrol a large number of your apps, we recommend focusing on your most popular apps only.
1.12 We need user defined egress - e.g. admins allowing domains via UI. Otherwise some apps including one of our own will not be able to achieve the new cloud security badges.
This is currently being built out as part of the customer managed egress project (now in EAP), and apps that allow customers to define egress domains will be eligible for A4A as the egress will be fully under the customers’ control.
5.1 accessibility tested: This seems unecassary in terms of a secure app. For us this is just another hurdle which introduces more costs.
As I mentioned to @Chris_at_DigitalRose above, the A4A program is intended to cover more than security. The requirements are designed to help IT admins have confidence that the app has “ticked all the boxes” as they go into their procurement process.
For many larger customers, accessibility is becoming a mandatory requirement for any software they purchase.
6.1 automated migration path: This really irritates me the most. For our apps there is no automated migration path,
because Atlassian does not offer the needed mechanisms.
Example app1: No mapping of customfield context ids from DC to cloud => no way of migrating our app data automatically. Open Bugs about this for many years.
Example app2: No automated conversion of DC Confluence macro storage format to cloud storage format. Open Bugs for years.
=> I vote to leave the while point 6.1 out of the security badge, because this is mostly out of an App Vendors scope to achieve even if he wants to.
This is good feedback, thank you.
Hi @tpettersen ,
While most of our apps are still on Connect (static content macros, which may or may not be built for Forge by Atlassian), we have also a ROA Forge app.
The app is CustomUI, and has no ADF export. The app works with PDF exports, and we get a “normal” render request from Confluence and return html+js. This gets rendered by Confluence for PDF.
I do not believe there is the possibility to throw an InvocationError , as all rendering is done in frontend code: our app returns html+js, and Confluence runs the js as if Confluence was a user’s browser. Confluence calls the Confluence APIs as our app. There is no resolver or backend call involved.
Hi, thanks for the RFP, good to see the trust signals evolve.
Lots has already been discussed on, but I’ll comment on the need to offer an automated migration pathway from DC to cloud. There is obviously a fair bit of nuance here as the migration documentation suggests - there is partial automation, “install only” options, etc. Indeed, some of our apps are “install only”, since they only rely upon parent app data. So at a minimum I’d ask that “install only” apps get a pass here.
More generally, we’ve found good success in creating migration tools that don’t use the CMA. Instead, we create our own UI which means we get much more control over the experience providing options and interactivity during execution. Since this still means we support customers moving from DC to the cloud, I hope it’d still be eligible, even if they are marked “manual”. I believe that this is relatively common in the ecosystem.
@PhilipGrove – Thank you for spending the time to address everyone’s concerns.
I’d like to ask a follow-up question about the Private vs. Public Bug Bounty program.
I understand the benefits of public vs. private, and I understand why a public program is a planned prerequisite for A4A qualification.
However, what is the benefit of requiring all programs to be public? Why not continue to offer private bounty programs that simply aren’t eligible for A4A status?
There is a lot of concern about queues becoming overwhelmed by public bounty programs. In this thread, Atlassian has basically responded with “it won’t be that bad.” (I’m paraphrasing.)
But the “Making your Bug Bounty Program Public” page that you linked to in the RFC begs to differ:
So, my question is why isn’t Atlassian continuing to provide private bounty programs as a stepping-stone towards a public program?
I feel like this is an example of how the new A4A program is going to incentivize the largest vendors to invest in the exclusive badge, while disincentivizing everyone else from making much of an investment at all.
Hi @PhilipGrove,
Thanks for the continued clarifications on this RFC. We’re reviewing the A4A requirements for Structure (Tempo) and have a few questions we couldn’t find addressed in the thread:
OAuth Tokens (Req 1.4)
The app does not collect or store credentials belonging to Atlassian user accounts
One of our features requires 3LO, so we store OAuth tokens. Can you confirm these are not considered “user credentials” under this requirement?
Egress Declaration for Forge Remote (Req 1.12)
For apps using Forge Remote with an external backend:
- Where should egress domains be listed – in manifest.yml or elsewhere?
- Is there a limit on the number of egress domains?
- For customer-provided egress (e.g., customer enters a URL to integrate with a third-party service) – do we need to list these? If yes, where and how?
asUser() vs asApp() (Req 1.15)
App must default to asUser() when performing an action on behalf of the user
Is asApp() acceptable for loading shared data that is accessed by multiple users, where user-level access control is handled separately by the app?
Thanks for any guidance on these.
Hey @MartinWood, thanks for your feedback.
Indeed, some of our apps are “install only”, since they only rely upon parent app data. So at a minimum I’d ask that “install only” apps get a pass here.
More generally, we’ve found good success in creating migration tools that don’t use the CMA. Instead, we create our own UI which means we get much more control over the experience providing options and interactivity during execution. Since this still means we support customers moving from DC to the cloud, I hope it’d still be eligible, even if they are marked “manual”. I believe that this is relatively common in the ecosystem.
This is good feedback. The migration requirement is one I will be reviewing more closely based on the feedback received as part of this RFC.
@PhilipGrove Thank you for your comments about outbound domains, data residency, LLMs – proposed formulations sound better.
Could you please also comment on my concerns regarding logging UGC data?
Thank you for the opportunity to weigh in on these changes and a very thorough RFC, Phil! The framing of “where” and “how” definitely helps delineate these signals.
High level commentary from the Gliffy team:
-
We support changes that help communicate mature product security and practices—we’re aligned with the overall goal of this initiative.
-
Looking forward to clarity on timelines.
-
The number one way to increase trust in the program/any badging is by Atlassian taking on the responsibility to verify/validate against requirements.
We discourage a prescribed requirement to use Forge LLM when the capabilities are available as this may introduce rework and penalize vendors who want to pursue AI innovation on an earlier timeframe. If the goal is building trust in how AI capabilities are added by Marketplace Vendors, it should focus on the vendor’s practices and responsible use of AI rather than the choice of a specific model (ie ISO 42001). This feels appropriately focused on defining “How” vs prescriptive.
We would also discourage including migration-related requirements here. If a vendor can provide a faster/more efficient path or is required to handle that path in a different way, I don’t think it makes sense to penalize them. Further, these requirements feel outside scope for both the “where” and “how” articulated by the Cloud badging strategy you’ve outlined.
Happy to discuss 1:1. Thank you again. 
(PS- Not sure how to change my username here right now. Samie Delebo since June!)
Hi @PhilipGrove ,
A related issue tangential to the new trust program is guest user access in Confluence. Guest users are special users with very restricted access (e.g. for external users). Apps can now work with guest users, however we must use asApp() with them, leading easily to information disclosure or security issues because we can’t use asUser() (see https://developer.atlassian.com/platform/forge/access-to-forge-apps-for-unlicensed-users/#frontend-bridge-calls-from-unlicensed-users and Jira )
I think it would be great if Atlassian could facilitate a safe usage of their APIs.
Hey Artemii, thanks for your feedback and welcome to the community!
One of our features requires 3LO, so we store OAuth tokens. Can you confirm these are not considered “user credentials” under this requirement?
Let me come back to you on this one.
For apps using Forge Remote with an external backend:
- Where should egress domains be listed – in manifest.yml or elsewhere?
These would be listed in the Forge manifest under the remotes or permissions.external properties
- Is there a limit on the number of egress domains?
We recommend no more than 50 egress domains.
- For customer-provided egress (e.g., customer enters a URL to integrate with a third-party service) – do we need to list these? If yes, where and how?
No, these don’t need to be added.
Is asApp() acceptable for loading shared data that is accessed by multiple users, where user-level access control is handled separately by the app?
Yes, using asApp() to load shared data is acceptable under our public security requirements so long as that data is conceptually owned by the app (e.g., workspace- or project-level configuration), tenant isolation is preserved, and your app performs user-level authorisation checks before any asApp() read or write so that asApp() is not used to bypass/escalate product permissions or expose data to users who should not see it.
Hey Samie, thanks for your considered feedback.
We support changes that help communicate mature product security and practices—we’re aligned with the overall goal of this initiative.
The number one way to increase trust in the program/any badging is by Atlassian taking on the responsibility to verify/validate against requirements.
Great to hear and 100% agree!
We discourage a prescribed requirement to use Forge LLM when the capabilities are available as this may introduce rework and penalize vendors who want to pursue AI innovation on an earlier timeframe. If the goal is building trust in how AI capabilities are added by Marketplace Vendors, it should focus on the vendor’s practices and responsible use of AI rather than the choice of a specific model (ie ISO 42001). This feels appropriately focused on defining “How” vs prescriptive.
@AdamMoore responded to @oliver.straesser above, suggesting an update to the requirement, being:
“Uses Forge LLMs or has publicly documented Responsible AI policies and controls" that can be linked to”
Do you agree that this better defines the use of AI in apps?
We would also discourage including migration-related requirements here. If a vendor can provide a faster/more efficient path or is required to handle that path in a different way, I don’t think it makes sense to penalize them. Further, these requirements feel outside scope for both the “where” and “how” articulated by the Cloud badging strategy you’ve outlined.
The migration requirement is one we will be reviewing more closely based on the numerous feedback received as part of this RFC.
Hi @clouless, for your Example apps1, are you referring to https://jira.atlassian.com/browse/MIG-1994?
Can you link to the Example apps2 ticket?
Thanks in advance!
Hey, Samie Delebo, thank you for your feedback.
May I ask if you are referring to a migration path for Gliffy Diagrams | Zero Egress & Isolated Cloud-Ready?
Thanks in advance!
Hi @PhilipGrove
Thank you for providing detailed information about the Trust Program!
I have some questions that are directly related to our products.
We are currently waiting for public APIs to replace existing private endpoints. It would be great to provide a public API for all data that is stored on the Atlassian side. For example:
and others.
We would like confirmation that rate-limiting headers are now consistently provided for all REST endpoints. Our 2023 investigation showed inconsistent implementation.
For now, when using bulk APIs, most APIs return only some of the necessary information. Because of that, it is necessary to execute an additional request to obtain information from each entity. Are there any plans to expand bulk APIs?
Also, in our products, hitting a rate limit during export causes a hard stop. We would be great to discuss how “graceful degradation” is expected to work for high-volume data exports without breaking the core functionality.
We ensure full disk encryption and authorized access on our side. However, we would appreciate clarification on the boundary of responsibility when a user exports data (using our products) to their own storage/BI tools.
Best regards,
Roman