RFC-133: Evolving the Marketplace Trust Program (follow up to RFC-124) - Trust program requirement updates and validation steps

General Request for Comments (RFC)
, , , ,
1

RFCs are a way for Atlassian to share what we’re working on with our valued developer community.

It’s a document for building shared understanding of a topic. It expresses a technical solution, but can also communicate how it should be built or even document standards. The most important aspect of an RFC is that a written specification facilitates feedback and drives consensus. It is not a tool for approving or committing to ideas, but more so a collaborative practice to shape an idea and to find serious flaws early.

Please respect our community guidelines: keep it welcoming and safe by commenting on the idea not the people (especially the author); keep it tidy by keeping on topic; empower the community by keeping comments constructive. Thanks!

Project Summary

Back in January, we published RFC-124: Evolving the Marketplace Trust Program, where we outlined our plans to evolve the Marketplace Trust program.

In that RFC, we announced a new trust program, provisionally called Architected for Atlassian (A4A).

This RFC focuses on refining the requirements for this new trust program and the validation methods Atlassian will use to ensure they are met.

Broader topics from RFC‑124 (e.g. Marketplace UI changes, trust signals & filters) are out of scope for this RFC and will be covered via separate comms.

The initial proposal for the new trust program outlined 31 eligibility requirements across seven categories: Security, Reliability, Performance, Privacy & Compliance, Accessibility, Migration, and AI & Responsible Use. We received strong engagement and thoughtful feedback on these requirements.

In response, we’re publishing this second RFC that introduces a refined set of requirements and provides additional detail on how we plan to objectively validate each one.

Asks

When responding to this RFC, we’d especially appreciate feedback on:

  • Clarity & objectivity: Are there any requirements where the wording or the validation method feels vague, subjective, or open to inconsistent interpretation? Please provide suggestions on how this could be improved.
  • Evidence expectations: For requirements that rely on your trust center or documentation (e.g. logging, architecture diagrams, subprocessors), is it clear exactly what you’d need to publish?
  • Gaps: Are there any critical enterprise trust expectations you believe should be in the Enterprise‑Ready program but are currently deferred or missing?

Dates

Publish: 24 April, 2026

Discuss: 7 May, 2026

Resolve: 13 May, 2026

What’s changed since RFC-124?

TL;DR;

Based on feedback from RFC‑124 and follow‑up partner conversations, we have:

  1. Renamed the program: From Architected for Atlassian to Enterprise‑Ready to better reflect that this trust program is aimed at enterprise buyers and procurement teams.

  2. Refined the requirement set: The original 31 requirements have been reviewed. Some requirements have been updated, some deferred to later versions of the program, some removed, and a small number of new requirements added.

    • We have deferred requirements that were subjective or platform‑dependent: Requirements that partners flagged as subjective or heavily dependent on evolving Atlassian platform capabilities have been moved to the “Deferred requirements” section and will be revisited as the platform and program mature.
    • We have removed migration and Responsible AI conformance: Migration‑specific requirements and broad Responsible AI conformance are no longer part of Enterprise‑Ready requirements.
    • We have added transparency‑focused requirements: In response to partner and customer feedback, we’ve introduced new requirements around transparency e.g. architecture/data‑flow diagrams, logging practices, and clearer documentation of subprocessors.

  3. Documented validation steps for each requirement: For each existing and newly added requirement, we detail how Atlassian will verify that it is met, so partners can clearly anticipate what will be required.

“Architected for Atlassian” is now “Enterprise-Ready”

The goal of this new trust program is to:

“Simplify enterprise customers’ discovery and procurement of Marketplace apps”

After feedback from both partners and customers, we felt that “Architected for Atlassian” did not clearly convey the audience segment we are aiming for (enterprise customers). We want to be careful to ensure customers understand that the new trust program is intended for enterprise buyers. These are customers with complex, onerous procurement processes.

The new program isn’t for every customer, and we want to avoid customers over-indexing on apps being a part of this new trust program.

Also, partner feedback raised via RFC‑124 and via direct conversations consistently raised concerns that:

  • The name “Architected for Atlassian” did not clearly convey trust and may, instead, increase rather than reduce confusion.
  • The term “Architected for Atlassian” sounded like an engineering or platform‑alignment claim (e.g. “built for Atlassian”), rather than a verified trust standard.

This new trust program is deliberately setting a high bar, and if the name doesn’t clearly communicate “trust”, we risk:

  • Failing to address the enterprise customer problem that the program is meant to solve
  • Undermining the value of the investments we’re asking partners to make.

With this in mind, the program has been renamed “Enterprise-Ready,” which we feel clearly communicates its goal and intended audience.

Updated requirements

This section only includes requirements whose wording changed since RFC‑124. See the full list below for the current Enterprise‑Ready requirements and how they’ll be validated.

1.0 - Security

  • 1.1 - Evidence that a current annual penetration test has been completed. This could be the report behind NDA on your trust centre or an attestation letter from your CREST accredited pen test provider.

    • Changed from: Annual penetration testing report available. Penetration tests must be carried out by a CREST-accredited company

  • 1.5 - The app does not collect or store credentials belonging to Atlassian user accounts, such as user passwords or personal API tokens, unless the app has an approved PAT usage exemption documented via an ADDON ticket.

    • Changed from: The app does not collect or store credentials belonging to Atlassian user accounts, such as user passwords or user API tokens.

  • 1.6 - Any Atlassian end user data stored outside the Atlassian product or users’ browsers must use full disk encryption at rest (including any app logs)

    • Changed from: All data at rest must be encrypted

  • 1.8 - The app logs must not include personal data, or credentials.

    • Changed from: The app logs must not include UGC content*, personal data**, or credentials.

  • 1.11 - The app must not use end-of-life NodeJS runtimes

    • Changed from: The app must not use unmaintained/deprecated libraries or end-of-life NodeJS runtimes

  • 1.12 - All “first hop” outbound (egress) domains must be explicitly listed to prevent unrestricted network access. Any additional egress, e.g where the customer chooses which domains they egress to, must be under customer control and fully auditable.

    • Changed from: All outbound (egress) domains must be explicitly listed to prevent unrestricted network access.
    • Notes:
      • subdomain wildcards (.domain.com) are acceptable, while full wildcard () entries are not.
      • “first hop” is defined as the first stop your data makes after leaving your app.

3.0 - Privacy & Compliance

  • 3.3 - If an app stores data remotely, it should support Data Residency (pinning and migration).

    • Changed from: The app supports Data Residency (pinning and migration)
    • Notes:
      • There is no mandatory requirement to support any specific regions.
      • Apps that only store data within the host product (Jira, Confluence, etc.) meet this requirement.

  • 3.4 - The app clearly discloses all third-party integrations and subprocessors, along with data retention and deletion policies, for any data egressed from the app

    • Changed from: The app clearly discloses all third-party integrations, along with data retention and deletion policies, for any data egressed from the app

4.0 - Accessibility

  • 4.1 - The app has a Voluntary Product Accessibility Template (VPAT) publicly available.
    • Changed from: The app has been accessibility tested, and a Voluntary Product Accessibility Template (VPAT) is publicly available
    • Notes:
      • Accessibility testing can be automated or performed manually.
      • No mandatory accessibility level is required.

5.0 - AI & Responsible Use (if the app uses AI)

  • 5.1 - If the app uses AI, there is a publicly available AI usage policy (ideally on the partner trust centre).
    • Changed from: The app uses Forge LLMs where practical, and may only use external AI services for scenarios that Forge LLMs don’t support. For example, when a use case requires a custom‑trained model or a modality that Forge LLMs don’t provide.

Deferred requirements

Based on partner feedback and further internal discussions, we’ve decided to defer the requirements below. We will revisit program requirements annually.

1.0 - Security

  • 1.8 - The app is not using private/undocumented Atlassian API endpoints
  • 1.14 - Respects rate-limiting headers

2.0 - Reliability

  • 2.1 - The app consumes APIs efficiently (utilising bulk APIs, field expansion & limiting parameters where appropriate) and scales to enterprise data volumes and activity thresholds. User experiences degrade gracefully with appropriate user and admin messaging when rate limits are exceeded.
  • 2.2 - Publicly defined SLI/SLO reliability metrics

3.0 - Performance

  • 3.1 - Performance requirements are still being considered.

Removed requirements

Based on partner feedback and further internal discussions, the following requirements have been removed from the program.

6.0 - Migration (if the app has a DC equivalent)

  • 6.1 - The app has an automated migration path from Data centre to cloud
  • 6.2 - Migration documentation is publicly available
  • 6.3 - Feature parity documentation is publicly available

7.0 - AI & Responsible Use (if the app uses AI)

  • 7.1 - The app conforms to Atlassian’s Responsible Technology Principles

New requirements

The following requirements have been added. We welcome feedback on these new requirements.

1.0 - Security

  • 1.3 - If the app processes or stores data outside of Atlassian’s infrastructure, an architecture, data flow or network diagram should be publicly available (ideally on your trust centre)
  • 1.9 - The app must publicly document (ideally on your trust centre) what data is stored in the app logs and the retention period of these logs.
  • 1.15 - App developers must ensure that any external services their app calls are only accessible over HTTPS with TLS 1.2+ (or higher).
    • Notes**:**
      • Forge‑managed egress already enforces this, so this requirement applies to any additional outbound connections or infrastructure the partner controls.
      • This requirement is already part of the current security requirements for Cloud Apps.
  • 1.16 - Apps must not use third‑party dependencies or packages with known vulnerabilities, especially Critical and High severity vulnerabilities, and must prioritise patching when new vulnerabilities are disclosed.

2.0 - Reliability

  • 2.3 - Partner must respond within 1 day (24 hours) to critical customer support issues, 5 days a week, in the Marketplace Partner’s local timezone.

Full Enterprise Ready requirement list with validation steps

Below is the complete list of requirements, along with how Atlassian plans to validate each. Your feedback here is very much welcomed.

1.0 - Security

  • 1.1 - Evidence that a current annual penetration test has been completed. This could be the report behind NDA on your trust centre or an attestation letter from your CREST accredited pen test provider.

    • Validation:
      • App has a pen test report from our Bugcrowd pentest program in the past year
      • OR app has a pen test from an approved CREST vendor, and the partner has submitted for approval via ECOHELP in the past year.

  • 1.2 - Public (or in the process of becoming public) security vulnerability reporting using Atlassian’s Bug Bounty program.

    • Validation:
      • App has a public (or in the process of becoming public) bug bounty program without any major violations (unpaid submissions, etc)

  • 1.3 - If the app processes or stores data outside of Atlassian’s infrastructure, an architecture, data flow or network diagram should be publicly available (ideally on your trust centre)

    • Validation:
      • Partner supplies a link or indicates that this is available on their trust centre. Note: This can be protected by an NDA or a password.

  • 1.4 - The app does not use any Connect modules

    • Validation:
      • Ecoscanner does not detect Connect module definitions in the Forge manifest.

  • 1.5 - The app does not collect or store credentials belonging to Atlassian user accounts, such as user passwords or personal API tokens, unless the app has an approved PAT usage exemption documented via an ADDON ticket.

    • Note:
      • OAuth and other short‑lived access tokens must only be cached in memory with a TTL no longer than the token’s expires_in value and must not be stored beyond their lifetime. Alternatively, store them in Forge Secret Storage, with a TTL that does not exceed the expires_in value.
    • Validation:
      • Ecoscanner does not detect any Personal API Token collection or usage logic in the app code. It will do this by checking:
        • The frontend UI code contains no forms or prompts that request user PATs.
        • The backend code does not store any user PATs.
        • The backend code does not call any Atlassian APIs using a PAT token in the Authorisation header.

  • 1.6 - Any Atlassian end user data stored outside the Atlassian product or users’ browsers must use full disk encryption at rest (including any app logs)

    • Validation:
      • Your public trust centre must explicitly list data encryption at rest for customer data.

  • 1.7 - The app only requests access to the data it needs (least privileged access)

    • Validation:
      • Ecoscanner does not find any excessive permissions being requested that are not utilised in the code.

  • 1.8 - The app logs must not include personal data or credentials.

    • Note:
      • “personal data” is defined as information about an identified or identifiable natural person, or which otherwise constitutes “personal data”, “personal information”, “personally identifiable information” or similar terms as defined in Applicable Data Protection Law.
    • Validation:
      • If you are using Forge logs:
        • We will continuously monitor app logging behaviour for any patterns of personal data logging and flag them to developers via an Ecoscanner vulnerability.
        • Note: these scans are not exhaustive. You remain responsible for verifying that personal data is not recorded.
      • If you are using remote logging:
        • We will rely on the new requirement “The app must publicly document (ideally on your trust centre) what data is stored in the app logs and the retention period of these logs.” for this.

  • 1.9 - The app must publicly document (ideally on your trust centre) what data is stored in the app logs and the retention period of these logs.

    • Validation:
      • Partner supplies a link or indicates that this is available on their trust centre. Note: This can be protected by an NDA or a password.

  • 1.10 - Any Atlassian End User Data accessed by an application or a service should be authenticated and authorised appropriately

    • Validation:
      • Ecoscanner does not detect any unauthenticated web triggers or REST APIs exposed on the Forge app.
      • Ecoscanner does not detect unauthenticated & unauthorised remote hosts defined in the Forge manifest remote list

  • 1.11 - The app must not use end-of-life NodeJS runtimes

    • Validation:
      • Ecoscanner does not detect any EOL NodeJS runtime versions in the Forge app manifest runtime.

  • 1.12 - All “first hop” outbound (egress) domains must be explicitly listed to prevent unrestricted network access. Any additional egress, e.g where the customer chooses which domains they egress to, must be under customer control and fully auditable.

    • Note:
      • Subdomain wildcards (.domain.com) are acceptable, while full wildcard () entries are not.
      • “first hop” is defined as the first stop your data makes after leaving your app.
    • Validation:
      • Ecoscanner does not detect any broad wildcards in the Forge app manifest
      • All default egress domains are explicitly listed.
      • No full wildcard () or (.com) TLD wildcard entries are used.

  • 1.13 - Vulnerability Scanning

    • Validation:
      • The app must include CI/CD checks to prevent introducing common security vulnerabilities, such as Secrets or Forge security misconfigurations, and npm vulnerabilities.
      • App owners must patch any reported vulnerability Critical/High tickets before onboarding.
      • After onboarding, participating apps must maintain a net introduction rate below the median for detectable SAST vulnerabilities that can be caught by vulnerability-scanning gating.

  • 1.14 - App must default to asUser() when performing an action on behalf of the user

    • Validation:
      • Ecoscanner does not detect usage of privilege escalation without validating user permissions for the action.
      • When a user initiates an action that uses AsApp(), the app first confirms that the user has the required permissions to access the target resource before executing the request.

  • 1.15 - App developers must ensure that any external services their app calls are only accessible over HTTPS with TLS 1.2+ (or higher).

    • Note:
      • Forge‑managed egress already enforces this, so this requirement applies to any additional outbound connections or infrastructure the partner controls.
    • Validation:
      • Ecoscanner will validate HTTPS, and newer TLS versions are supported by external egress points defined in the Forge manifest.

  • 1.16 - Apps must not use third‑party dependencies or packages with known vulnerabilities, especially Critical and High severity vulnerabilities, and must prioritise patching when new vulnerabilities are disclosed.

    • Validation:
      • There are no open AMS tickets of High/Critical severity at onboarding, and you continuously fix vulnerabilities within the Marketplace bug fix policy timeline without violations.

2.0 - Reliability

  • 2.1 - Publicly documented incident management process, including a public Statuspage

    • Validation:
      • Partner has provided an active Statuspage or similar tool for tracking system health and for proactive customer communications during incidents.
      • Partners has a well-documented incident management process, including the following elements:
        • Incident detection, triaging and classification.
        • Incident resolution timelines.
        • Post-incident analysis and prevention.

  • 2.2 - Participation in a collaborative incident response program with Atlassian

    • Validation:
      • Partner has provided a 24/5 email mailbox and emergency phone security contact for security alerts. Contact must preferably be a security professional or third third-party Security Operations Centre. Alternatively, the technical lead of the app.
      • Partner collaborates with Atlassian during security incidents following the Atlassian-defined incident response process and communications channel.
      • Partner must respond to alerts within 8 hours.
        • Atlassian will conduct random test security incident notifications to validate partners have the correct contacts and are responding within SLA during business hours.
      • Notifies Atlassian of any security incidents impacting customers.
        • Atlassian will utilize customer escalations and breach monitoring services to identify undisclosed security incidents.

  • 2.3 - Partner must respond within 1 day (24 hours) to critical customer support issues, 5 days a week, in the Marketplace Partner’s local timezone.

    • Validation:
      • Atlassian will conduct random support request tests to validate that partners have the correct support contacts in place and are responding within SLA.

3.0 - Privacy & Compliance

  • 3.1 - Public trust centre available

    • Validation:
      • Ecoscanner has identified that the Trust Centre link included in the app listing is accessible to the public and originates from a supported third‑party provider.
        • List of supported providers: Vanta, Safebase, Drata, Sprinto, TrustShare, Comp AI, Conveyor, Delve, Scrut Automation, SecureFrame, TrustCloud, UpGuard, AuditBoard, OneTrust, Thoropass, Whistic
      • Trust centres not currently supported can request a manual review by Atlassian for exceptions. These must meet the feature parity of other vendors, for example:
        • The site is public, not requiring a password or personal information to view
        • Certifications are visible as badges, and certificates can be viewed
        • Audit reports can be requested and viewed by customers.

  • 3.2 - SOC 2 Type 2 or ISO27001 compliance

    • Validation:
      • Ecoscanner checks for compliance frameworks that are explicitly mentioned on the public trust centre.
        • SOC2 Type II or ISO27001 badges are listed under Compliance Certifications
        • SOC2 Type II or ISO270001 report is available under Resources on the Trust centre. Audit reports can be protected by NDA or passwords.

  • 3.3 - If an app stores data remotely, it should support Data Residency (pinning and migration).

    • Note:
      • There is no mandatory requirement to support any specific regions.
      • Apps that only store data within the host product (Jira, Confluence, etc.) meet this requirement.
    • Validation:
      • For Runs on Atlassian:
        • The app uses only Forge storage modules, meaning Data Residency pinning and migration support is built in.
      • For Forge Remote:
        • The apps manifest contains:
          • region-specific URLs in baseUrl
          • use of migration:dataResidency module

  • 3.4 - The app clearly discloses all third-party integrations and subprocessors, along with data retention and deletion policies, for any data egressed from the app

    • Validation:
      • Partner supplies a link or indicates that this is available on their trust centre. Note: This can be protected by an NDA or a password.

  • 3.5 - Publicly available privacy policy

    • Validation:
      • Privacy policy is shown on the app listing
      • Atlassian will manually review the privacy policy during initial app onboarding, then continuously monitor for health.
      • Ecoscanner crawler detects a publicly available privacy policy page that doesn’t return a 404.
      • The page contains privacy policy language
      • Privacy policy is hosted on the same domain as the partner’s main website.

4.0 - Accessibility

  • 4.1 - The app has a Voluntary Product Accessibility Template (VPAT) publicly available.
    • Notes:
      • Accessibility testing can be automated or performed manually.
      • No mandatory accessibility level is required.
    • Validation:
      • Partner supplies a link or indicates that this is available on their trust centre. Note: This can be protected by an NDA or a password.

5.0 - AI & Responsible Use

  • 5.1 - If the app uses AI, there is a publicly available AI usage policy (ideally on the partner trust centre).
    • Validation:
      • Partner supplies a link or indicates that this is available on their trust centre. Note: This can be protected by an NDA or a password.

If you would like to provide feedback in a 1:1 conversation, please use this RFC: Partner Feedback form.

5 Likes
2

“Enterprise-ready”: if you pay the $2-5k/yr/app pentesting requirement.

Not “enterprise-ready”: if you don’t pay up.

The language choice here literally signals to potential customers that any app without this badge is not fit for enterprise-use AND THEN you’re paywalling that badge so that only the top few % of apps will be able to justify the cost.

What impact do you think that will have on total marketplace installations and revenue?

1 Like
3

Ok, against better judgement I’m going to restart the discussion on the naming.

Enterprise-Ready is still a very misleading name. Not only is the definition of Enterprise unclear, it now seems to make an objective claim because of the ready part.

The requirements are subjective and defined by Atlassian. Not meeting these requirements does not mean that an app is not Enterprise ready.

We have been serving Enterprises since 2012. Is Atlassian trying to say that we are not Enterprise ready? That would be very weird, especially considering that we’ve been happily serving Forbes 500 customers for the past 14 years. They considered us Enterprise ready.

I know naming is hard. But Atlassian needs to avoid trying to make objective claims, because there is no universally objective standard on what “Enterprise-ready” means.

I would rather see something like Atlassian Verified or Atlassian approved or something that denotes the fact that this meets Atlassian standards instead of a generic claim.

5 Likes
4

I wish Atlassian would put their own house in order first.

I have a Premium subscription to your apps, but it doesn’t stop your system from randomly cancelling vital marketplace app subscriptions without warning. Very enterprise-ready. How are we supposed to use this software if it randomly cripples itself from time to time.

I know the above is not exactly related to RFC-133, but really, this RFC sounds like another example of “do as I say, not as I do”.

Another symptom of the Atlassian System of Busy Work for everybody else.

*This message is regarding the huge frustration with the Atlassian entity, and is not personally targeted at any single person who happens to be representing that entity at any particular time.

1 Like
5

And that’s if customers can successfully install your app in the first place.

6

Firstly, I think the label, Enterprise-Ready is much better than the earlier proposed “Architected for Atlassian (A4A)”.

Thank you for listening to feedback. I understand some of the concerns posted above, though no label is going to reflect everything that is covered under the program.

Now on to the actual list:

This is a huge mistake given the current problem with app versioning. I do not want to repeat the versioning issue again, because it has already been discussed tons. It would make sense if an app requests admin permission but only needs read. But granular permissions on Forge are very messy combined with current versioning rules.

Again, a huge mistake if you do this before fixing current platform issues. I am honestly baffled that this is proposed while we have been begging for a fix to the underlying issues since the Forge platform existed. We have to use wildcard egress in order to be able to open links in a new tab.

I guess this is trying to accommodate Customer Managed Egress (CME) which is currently in EAP and won’t be ready anytime soon.

This is reasonable, but please give us a simple API / interface to check permissions when using asApp like user.hasPermission(‘page:read’). Currently, we have to make multiple API calls to do this and often require new permission scopes (which creates a major version).

The overall requirements look great on paper, and every enterprise team involved in procurement looking into this would appreciate the framing. However, Atlassian is ignoring their roles and responsibilities as a provider of a fully managed app platform and completely offloading all the work to vendors. Mainly, the Forge Platform is NOT ready to accommodate all the practical issues vendors will face when trying to comply with these requirements while still maintaining fairly usable apps.

9 Likes
7

@PhilipGrove – This proposal shows substantial improvement over the last one. I agree with much of the critical feedback (above), but regardless, this iteration is much stronger than the first one (IMHO). It’s clear you gave due consideration to the community’s feedback. Thank you!

Regarding the program name…

I agree with this:

But I also agree with this:

Just call the program what it is: “Atlassian Trust Certified”.

That name (or something similar) is much more transparent and honest than “Enterprise-Ready”.

As Remi already pointed out, the absence of the “Enterprise-Ready” badge does not mean an app isn’t suitable for a large enterprise. And let’s be honest with ourselves, obtaining the badge isn’t a guarantee that an app is suitable for a large enterprise either. That name is misleading in both directions.

“Atlassian Trust Certified” (or similar) is much more objective and meaningful, especially since you have done work to make the requirements less subjective. If an app has the badge, it means Atlassian has certified it. If an app doesn’t have the badge, Atlassian hasn’t certified it. Those are facts, not opinions, and thus much more meaningful to customers.

5 Likes
8

1.12 Any additional egress … must be under customer control and fully auditable.

What does “fully auditable” actually entail? I.e. what information do we need to store about what data was egressed and how does it need to be accessible, for how long etc.?

Just to be sure as well on what egress means in this context, does it include “egressing” (some) data in order to fetch additional data from an external domain? Say we have a feature that actually ingresses data (say from Github) but in order to fetch it, we need to egress a customer’s email address via the API to search for this users’ data (commits) in Github.

Deferred Reliability and Performance

Please do explicitly consider before bringing these back, that Atlassian APIs often don’t support bulk API or when bulk APIs are offered they come with restrictions that make them not as efficient as it might seem. The “bulk” user API is an example. It does not return all the information we need about a user in all cases, so we need to call back out for each user via the individual user API. On top of that, because it’s using GET it is also severely limited in the number of users one can fetch in one go (less than 50), because of Atlassian server’s header size limits. The ticket to provide a POST version was simply closed after some time.

9

I agree that the new name is better than A4A, but it is still missing the mark. As others have mentioned above, the absence of a particular badge implies that an app that does not have the badge does not have the attribute. So, if it’s “Architected for Atlassian”, then an app missing the badge is “Not architected for Atlassian”. Similar for the implication of apps being “Not Enterprise-Ready” because they do not have the Enterprise-Ready badge.

I also agree that this program is objectively a certification. I also believe there may be tension because Atlassian legal does not want you to say that you are “certifying” products for [insert legal/liability reasons here].

Regardless of what legal thinks, the inherent problem is that “certification” is still exactly what you are doing. To that end, “Enterprise Certified” nails exactly what this program does and it should be very clear to everyone involved.

If legal is indeed the problem, perhaps you could have a chat with them to see if there is any wiggle room? There are enough asterisks and superscript double-daggers foisted on customers with all of the recent AI stuff, so I would hope there would be some way around this here.

1.16 - Apps must not use third‑party dependencies or packages with known vulnerabilities, especially Critical and High severity vulnerabilities, and must prioritise patching when new vulnerabilities are disclosed.

Saying “especially critical and high” misses the mark here, and it also differs from the linked cloud security policy. The CSP prohibits critical and high vulnerabilities, period. This policy should be the same.

Note that it is not even really possible to ship Atlassian apps these days with absolutely zero vulnerabilities: if you do a baseline install of random @forge or @atlaskit components on any given day, it usually sucks in at least a couple of low- or medium-priority dependencies that are rarely fixed in a timely manner on Atlassian’s side.

Ecoscanner does not find any excessive permissions being requested that are not utilised in the code.

I also agree with earlier comments: the fragmentation of Forge permissions are a nightmare and vendors will likely want to request app permissions for not just current app features, but also those planned in the near future. Failure to do so leaves the vendor with a fragmented user base and/or a broken app, since customers rarely upgrade.

Perhaps you could meet the goals of this program by having the Ecoscanner coalesce permissions into larger groups (similar to Connect, like read/write/act_as_user/admin) and only flag excessive permissions if they fall outside an existing group. For example, it might flag a read-only app that requests write permission, if that app has no existing API calls to write data. I absolutely do not want my app to get flagged for requesting “write blogpost” permission when it already has “write page” permission, simply because I am getting around to implementing blogpost support and I do not yet have the blogpost-writing code added.

It is also important to clarify how Ecoscanner will determine what permissions “are used in the code”. Will it be performing real-time (or deferred) analysis of actual API calls through the API gateway over time, or will it be attempting static analysis?

Analyzing calls through the gateway is probably fine (and it works for Forge Remote), but it risks not catching certain actual API uses (for niche features) unless the time period is long enough.

In the case of static analysis, you cannot ask the Ecoscanner to perform a simple static analysis of Forge apps by attempting to analyze the URLs in the requestConfluence() or requestJira() calls, because many apps have abstraction layers that move this code elsewhere.

For example, the built-in API call permissions checker in forge lint is useless for one of my apps and it never catches anything, since the meat of the code lives elsewhere. If you were to use this code on my app, it would believe that the app makes no API calls at all.

4 Likes
10

‘Ready’ is highly problematic. So Atlassian is saying that currently apps are not ‘ready’? All apps without this label are vulnerabilities for companies?

Please reconsider this name, the name is key. Atlassian is making the same mistake again as it did with Cloud Fortified. Customers did not understand it, as a vendor I barely do. It needs to have clear and understandable value for customers. If not it is a make-work program for Vanta, testers etc.

Less is more. Enforce, test and explain less but well. Add requirements later as needed. Atlassian has cut staff. I’m not confident Atlassian will be able to manage this complexity. It’s hard not to see good intentions, the slide and spreadsheet look great, but reality is only a presentation.

I’m not against the word Enterprise, but Enterprise and Ready together are what I, as a native English speaker, call mumbo jumbo.

11

This is a good name. Well said, it has to say what it does.

So is @scott.dudley suggestion ‘Enterprise Certified’ (which is also shorter).

I get it @PhilipGrove you are trying to be witty, add some marketing to it, I generally support that. It would not surprise me if you got someone insisting on a 15 character limit (design team). Please push back on this. This needs to be a nerdy technical label, boring if needed. If not, it will not drive sales in the longer term.

Save the marketing for ‘system of work’ etc.

A former premier of Ontario (Canada) Bill Davis, 1970s-80s, became known for staying this when asked why he was in power for so long - bland works.

12

Another vote for “Atlassian Trust Certified” from @AaronMorris1 It aligns with the reality that this is a shopping list of items cherry-picked by Atlassian.