Raising the bar on Marketplace cloud app security: together

As more enterprise teams standardize on Atlassian cloud, Marketplace apps sit directly in the critical path of their work—and their data. Security and compliance teams keep coming back to the same questions:

  • How do I know this app has been properly tested?

  • Can security researchers report issues easily?

  • How quickly will vulnerabilities be fixed?

To help our partners answer those questions with confidence, we’re rolling out a set of new security programs and requirements for Marketplace cloud apps. Together, these changes are designed to:

  • Make security posture more transparent to customers by building a more comprehensive Bug Bounty program

  • Simplify and standardize app penetration testing, and surface clear trust signals to customers in the future

  • Align Marketplace vulnerability fix timelines with Atlassian’s own security practices

In this post, we’ll cover three key updates:

  1. A new Marketplace Penetration Testing Program

  2. A new requirement for Bug Bounty Programs to be public by default

  3. Shorter vulnerability fix timelines for Marketplace cloud apps

New Marketplace Penetration Testing Program

We’re excited to announce the launch of a new Marketplace Penetration Testing Program, available for partners to use today.

We’ve partnered with Bugcrowd to offer application penetration tests tailored for Atlassian Marketplace apps, at a flat rate of USD $1,000 per testing day. Tests are performed by experienced researchers who already understand Atlassian environments and common app architectures.

Atlassian is here to help and will support partners with:

  • Scoping – right-sizing the engagement based on your app’s size, complexity, and permissions (typically 2–5 testing days)

  • Testing and coordination – working directly with Bugcrowd and researchers

  • Reporting and triage – tracking vulnerabilities and remediation through the AMS Jira system

However, partners remain responsible for the set testing rate per day and patching all findings within the existing Marketplace Security Bug Fix timelines.

Why we’re doing this

In procurement conversations with enterprise customers, independent penetration testing consistently ranks among the most important security assurances for third‑party apps.

Before opening this program to partners, Atlassian’s internal security team prototyped and iterated on it over two years, running tests on 100+ apps. The result has been high‑quality, high‑signal vulnerabilities that meaningfully improved security posture. With that track record, we’re now making the same program broadly available to Marketplace partners.

Partner benefits

  • High-signal, low-noise testing: Curated researchers with Marketplace experience, scoped to your app

  • Operational simplicity: Atlassian handles coordination, logistics, and AMS vulnerability tracking

  • Customer-visible trust signals (future): Apps that complete penetration testing through this program will be eligible for a future Marketplace “Penetration Test” trust signal, enabling customers to filter for apps that invest more heavily in security

Partners who participated in our Early Access Program were extremely positive about the experience. As Daniel Wester from 55 Degrees put it:

“Pentesting Atlassian apps used to be a heavy lift for us — lots of setup, lots of explanation, and no guarantee the test would focus on our app rather than the platform. Atlassian’s new pentest program completely removed that friction. With Bugcrowd, onboarding was effortless, and the results were high quality. It was genuinely painless, and we now have strong confidence in the security assessment.”

And further praise for this program was echoed by Nicolas Esteves at Elements Apps:

“The new managed offering of the Marketplace Penetration Testing Program was a natural fit for us. It integrated seamlessly with our existing Bugcrowd-based security workflows, removed the need to source and manage a third-party vendor, and enabled meaningful cost savings compared to similar market offerings, while maintaining the depth and quality of the testing. It aligned exactly with what we were looking for."

No need to worry if you’re already under contract with another penetration testing provider; you can still benefit. We’ll support self-managed penetration testing by allowing you to submit equivalent reports to earn comparable trust signals, provided that:

  • Your provider is on the CREST‑approved penetration tester list, and

  • Findings are reported to Atlassian and are remediated within the Marketplace Security Bug Fix timelines.

Learn more here: Marketplace Penetration Testing Program

Sign up here: https://ww1.bugcrowd.com/atlassian-marketplace/

Bug bounty programs moving to public by default

To complement deeper testing, we’re strengthening our expectations around continuous vulnerability discovery.

What’s changing

For cloud apps, we will be requiring that:

  • All bug bounty programs are public by Jun 30, 2026

  • Programs are in “In Progress” status by Mar 1, 2026

    • “In Progress” constitutes that a ticket has been submitted via an ECOHELP ticket

Why public by default?

Our analysis of four years of bug bounty data shows:

  • Public programs are easier for researchers to find and participate in

  • They generate higher‑quality engagement and more meaningful findings

  • That, in turn, directly improves security outcomes for customers and partners

Public programs create a clear, incentivized, and documented path for researchers to report vulnerabilities in your app, rather than relying on ad‑hoc emails or informal channels. They also bring cloud apps closer into alignment with Atlassian’s security practices, where public vulnerability reporting channels and bug bounty engagements are core to our security posture.

What about noise and low‑value reports?

We know one of the biggest concerns about public bug bounty programs is “signal vs noise.” To address this, the transition will be:

  • Gradual, not overnight – a managed rollout, not a single‑day cutover

  • Scoped intentionally – before going public, you’ll work with Atlassian and Bugcrowd to:

    • Tighten scopes and targets

    • Adjust bounty ranges and researcher invitations

    • Set clear expectations for researchers to minimize low‑value submissions

You should expect some increase in report volume, but our goal is for that additional traffic to be high‑signal and manageable, not overwhelming.

Learn more here: Making your Bug Bounty Program Public

Raise an ECO-HELP to get started here: Request to Initiate Bug Bounty Program Public Transition

Shortening vulnerability fix timelines for Marketplace cloud apps

Stronger testing and public bug bounties only move the needle if vulnerabilities are actually fixed—fast. To bring Marketplace apps in line with Atlassian’s security SLAs and with what customers now expect from cloud services, we’re tightening the timelines for fixing Marketplace vulnerabilities in cloud apps.

What’s changing

Beginning on Mar 1, 2026, the timelines to remediate vulnerabilities in Marketplace cloud apps will be at parity with Atlassian’s internal bug fix policy, providing customers with consistent and clear expectations.

The changes to the vulnerability fix timelines are as follows:

Note: The updated SLAs only apply to cloud apps.

Phased enforcement

We’ll roll this out in two steps:

  1. From Mar 1, 2026

    • New AMS vulnerability tickets will show due dates based on the updated timelines.

    • This is an adoption period: you’ll see the new SLAs in the system, but violations will not yet be enforced.

  2. From Sep 1, 2026

    • The new timelines become enforceable.

    • Violations after this date may count toward Marketplace security compliance.

Between Mar 1, 2026 and Aug 31, 2026, partners who breach the new SLAs will receive violations but they will not be enforced. This window is designed to give you time to become aware of the change, understand its impact, and adjust your internal processes, staffing, and release timelines before the new SLAs fully take effect.

How we’ll support you

Shorter timelines for Critical and High vulnerabilities mean partners need to move quickly—but you won’t be on your own. Atlassian is preparing to:

  • Prioritize support for Critical and High issues impacting Marketplace apps

  • Expedite vulnerability triage and coordination, to minimize back‑and‑forth

  • Help partners interpret findings and confirm remediations so fixes can be shipped confidently within the new SLAs

Combined with the Penetration Testing Program and public bug bounties, these timelines ensure that:

  • Critical and high‑impact vulnerabilities are detected faster

  • They’re triaged through clear channels

  • They’re remediated within timeframes customers increasingly expect for SaaS and cloud ecosystems

Learn more here: Security Bugfix Policy | Atlassian

How can Marketplace Partners get started?

If you’re a Marketplace partner building cloud apps, here’s how to get started:

  1. Plan a penetration test for your key apps

  2. Prepare your bug bounty program to go public

  3. Review your vulnerability management process

    • Compare your current triage and release cadence against the new timelines:
      Security Bugfix Policy | Atlassian

    • Identify where you may need faster paths for Critical and High fixes (e.g., hotfix pipelines, on‑call for security, clear ownership).

    • Use the non‑enforced period between Mar 1, 2026 and Aug 31, 2026 to adapt your workflows.

By investing in these improvements together, we’re aiming for an ecosystem where Marketplace apps feel as trusted and secure as Atlassian’s own products—for admins, security teams, and end users alike.

We’re excited to partner with you on this next phase of Marketplace security.

2 Likes

This is an interesting initiative, but I wonder whether you can help me understand how it fits with the Security requirements for cloud apps, which require only critical and high vulnerabilities - and not medium or low - to be resolved. Will those requirements be updated? Or are you talking about two different types of vulnerabilities? In this case, would you please explain the difference?

1 Like

Hey Jacopo, great question. I lead the marketplace security team, for context the security requirements mandate that apps don’t contain Critical & High severity dependency type vulnerabilities.

That would include anything within the SBOM, if you manage your own scanning tools for SCA (Software Composition Analysis) in your CICDs or Atlassian reported dependency issues to you (we do), the expectation is you remediate critical & high severity issues.

On our end, we currently only ticket Critical & High severity SCA vulnerabilities with our own scanners, this is to cut down on noise on cloud apps. Which brings the question you had: what other types of vulnerabilities source could I get a medium or low from?

  • Vulnerabilities from our EcoScanner static code and dynamic code analysis tooling which can ticket all vulnerability severities including some Mediums.
    • Some examples: Expired domain checks, Forge and Connect specific vulnerabilities, excessive permission analysis, hardcoded secrets.
  • Vulnerabilities from the Bug Bounty program or Penetration Tests, these can include lower severities.

You’re still expected to fix these other vulnerability classes, even if they’re mediums or lows within the required marketplace security bug fix timelines. The good news is these are being extended to allow you to remediate critical & high issues with more urgency and capacity.

1 Like

Hi @ZacharyEchouafni ,

While I understand the policy to not include critical and high security dependency type vulnerabilities, it would help greatly if Atlassian would ship software not including these vulnerabilities.

As of today (2026-01-30) a fresh install of @forge/cli has: 15 vulnerabilities (7 low, 2 moderate, 6 high).

Also a fresh install of @atlassian/atlassian-connect-express has: 24 vulnerabilities (3 moderate, 19 high, 2 critical).

Additionally both contain outdated/unmaintained dependencies.

We need to use this software to build for Atlassian.

It went so far that one of our apps got flagged because of these vulnerabilities, and then we pointed out that this is due to an Atlassian dependency. Then the issue was dropped. We would much prefer to have secure dependencies.

11 Likes