For SaaS companies, the Atlassian Marketplace can open the door to a huge pool of businesses already using Jira, Jira Service Management, and Confluence. Atlassian says the Marketplace now has more than 6,000 apps, over 2,000 partners, and more than $6 billion in lifetime sales.
But getting an app in front of those buyers is only part of the job. Enterprise customers also want to know what the app can access, where their data goes, and whether another vendor could introduce new security risks. Verizon’s 2026 DBIR found that third parties were involved in 48% of confirmed breaches, compared with 30% in 2025.
That makes Atlassian Marketplace Security a real product requirement. The testing approach also changes depending on whether your app uses Forge, Connect, OAuth, or external services.
The rest of this guide breaks down what Atlassian expects, what testers look for, and where CREST testing comes into the picture.
Atlassian’s Shared Responsibility Model for SaaS Apps
Listing an app on the Atlassian Marketplace does not move all security responsibility to Atlassian. Your responsibilities depend partly on how the app is built. Connect, Forge, and OAuth integrations have different security boundaries, which directly affects what a penetration test needs to cover.
Forge Apps
Forge gives Atlassian greater control over areas such as the runtime, user authentication and platform storage. Your team still controls the app logic and how permissions are used.
Testing should therefore examine authorization, scopes, asApp() and asUser() behaviour, resolvers, web triggers, tenant isolation, business logic and connected APIs. Atlassian specifically requires apps to verify user permissions before appropriate asApp() requests. If the app sends data to external services, those systems also become part of the security boundary.
Connect Apps
Connect apps give vendors much more control because the app runs on infrastructure they manage. A penetration test can therefore cover the application server, APIs, storage, secrets, domains, and supporting infrastructure.
For Atlassian Marketplace Security, testing checks commonly:
- JWT and QSH validation
- Lifecycle callbacks and installation flows
- Shared secret protection
- Tenant identification
- Endpoint authorization
- TLS and security headers
- Domain ownership
Atlassian no longer allows new Connect apps to be published on the Atlassian Marketplace. Existing apps still need ongoing security testing and can move to Forge gradually.
Understanding Atlassian’s Trust Badges and Security Programs
Atlassian uses several trust signals to help customers judge whether an app meets its security and compliance expectations. Penetration testing is only one part of that system. Other checks look at areas such as vulnerability reporting, privacy, reliability, accessibility, and compliance.
Atlassian Enterprise Certified
Atlassian Enterprise Certified is designed for Forge Cloud apps that meet a higher set of enterprise requirements. The program covers security, reliability, privacy, accessibility, and responsible AI.
For security, vendors must show evidence of a current annual penetration test. Atlassian accepts either:
- A test completed through its Bugcrowd program within the previous year
- A test completed by an approved CREST provider and submitted to Atlassian for approval within the previous year
Cloud Fortified
Cloud Fortified is Atlassian’s existing trust program for cloud apps. You may still come across Cloud Fortified in older guidance, but Atlassian is replacing it with Atlassian Enterprise Certified. New Cloud Fortified submissions stopped on September 1, 2026, and the program is scheduled to retire on December 31, 2026.
For Atlassian security, vendors should therefore use the newer Enterprise Certified requirements when planning future compliance work.
Marketplace Penetration Testing Program
Atlassian offers a managed penetration testing option through Bugcrowd. The program uses grey box testing against the production version of each enrolled app and handles testing on a per-app basis.
Vendors can also use a CREST-accredited provider through Atlassian’s self-managed route, provided they follow the testing and submission requirements.
Ecoscanner and Bug Bounty
Ecoscanner continuously checks cloud apps for common vulnerabilities and missed security requirements. Atlassian’s bug bounty program adds ongoing researcher-led testing after an app is live.
A scoped penetration test serves a different purpose. Testers can spend more time on authorization issues, business logic flaws, and attack paths that need manual investigation.
These controls are designed to work alongside each other rather than replace one another.
Key Security Risks Unique to Atlassian SaaS Integrations
Some risks become more serious when an app connects directly with Jira or Confluence. Tenant separation, product permissions, and framework-specific authentication need particular attention because one mistake can expose data outside the intended account.
Cross-Tenant Data Leakage
A single app may serve many Atlassian customers. Poor tenant isolation can therefore expose one organisation’s data to another. It making SaaS security and proper tenant isolation critical.
Atlassian warns that Forge can reuse runtime processes between tenant invocations. Tenant-specific data kept in module-level variables or in memory caches may remain available unless it is scoped correctly. It also states that identifiers such as Jira issue keys and Confluence page IDs are not unique across tenants.
Testing should check areas such as:
- Issue, project, and page identifiers
- Caches and shared storage
- Background jobs
- Exports and attachments
- Callbacks and analytics
Use at least two separate Atlassian tenants when checking isolation. Different users within the same tenant are not enough to prove that customer data stays separated.
Broken Access Control
Authentication confirms who the user is. Authorization decides what that user is actually allowed to do. A valid Jira or Confluence account should never be treated as permission to access every function or record exposed by an app. Atlassian requires apps to authorize requests and, for Forge, to verify user permissions before using asApp().
Testing should compare access across roles such as:
- Unauthenticated users
- Low-privilege users
- Regular licensed users
- Project or space administrators
- Product administrators
- Organisation administrators
- Users from another tenant
Common failures include IDOR or BOLA, missing project or space permission checks, admin functions exposed to ordinary users, trusted client-supplied identifiers, privilege escalation, and cross-tenant object references.
Injection and Cross-Site Scripting
Data reaching an Atlassian app can come from many places beyond its own interface. Atlassian requires apps to validate and sanitise untrusted input before processing it, making SaaS application security an important consideration.
That input may come from:
- Jira issue titles, descriptions and comments
- Confluence pages and macro parameters
- Custom fields, labels and JQL or CQL inputs
- File uploads and imported JSON or CSV data
- Webhooks and external API responses
- App configuration values
Where relevant, testing should check for stored, reflected, and DOM-based XSS. Server-side testing may also cover SQL injection, command injection, template injection, path traversal, XXE, and SSRF. Atlassian specifically calls out injection risks and unsafe external requests in its Marketplace security guidance.
Insecure Data Storage and Transit
A review should follow Atlassian End User Data from the moment the app receives it until it is deleted. That includes checking:
- What data the app collects
- Where it is stored
- Who can access it
- Whether any third party receives it
- Whether logs contain sensitive information
- How deletion requests are handled
- What remains after the app is uninstalled
OAuth tokens, API credentials, Connect shared secrets, and other secrets also need secure storage. Atlassian says End User Data kept outside its own products or the user’s browser must be encrypted at rest.
For data in transit, Atlassian requires TLS 1.2 or later. Applicable infrastructure must also use HSTS with a minimum age of one year.
What an Atlassian Marketplace Penetration Test Evaluates
The scope should reflect how the app is actually built. Atlassian’s own penetration testing template asks vendors to define the framework, functionality, privilege levels, integrations, and other technical details before testing begins.
Framework Analysis
For Forge Apps
Forge testing should concentrate on the parts still controlled by the vendor, especially requested permissions, Custom UI components, and any remote services connected to the app. Atlassian applies different security requirements when Forge apps communicate with external systems.
For Connect Apps
Connect apps need broader coverage because more of the application runs on vendor-managed infrastructure. The assessment should therefore include the web layer, application configuration, and supporting server controls that sit outside Atlassian’s platform.
API Security and Webhooks
Once the framework itself is understood, the next step is to map every interface the app exposes.
Depending on the product, that may include:
- REST APIs
- GraphQL endpoints
- OAuth callbacks
- File upload and download routes
- Export functions
- Integration APIs
Testing can then look for problems such as:
- Mass assignment
- Excessive data exposure
- Missing rate limits
- Token replay
- Incorrect audience validation
- Acceptance of expired tokens
- CORS misconfiguration
- HTTP method manipulation
- Unsafe content type handling
These checks should be based on the interfaces the app actually exposes rather than applied as a fixed checklist.
OAuth and 3LO Integrations
OAuth 2.0 and 3LO flows introduce their own attack paths. Atlassian requires the state value to be tied to the user and difficult to guess. It also requires the redirect_uri used during authorization to match the callback configured for the app.
Relevant checks include:
- OAuth state validation
- Redirect URI manipulation
- Authorization code interception
- Refresh token handling
- Token revocation
- Scope minimisation
- Account linking errors
- Token exposure through URLs or logs
Atlassian also requires client secrets, access tokens, and refresh tokens to be stored securely.
Data Protection and Encryption
Review:
- Backups containing customer data
- Exported files stored outside the main application
- Copies created by support or diagnostic processes
- Dependency versions that can affect data security
- Unsupported runtime components
Atlassian prohibits cloud apps from using dependencies with known Critical or High severity vulnerabilities.
Automated Software Composition Analysis can help find risky packages, but the tester still needs to determine whether the vulnerable code path can actually be reached and exploited in the application.
AI-Enabled Apps
If the app includes AI functionality, the scope needs to expand beyond conventional web and API testing. Atlassian’s current penetration testing scoping template specifically asks vendors to disclose AI-related functionality when arranging a CREST assessment.
Testing may include:
- Prompt injection
- Disclosure of Jira or Confluence context
- Overly powerful AI actions
- Cross-tenant AI context leakage
- Unsafe external model connections
- Model output reaching privileged functions
- Secrets appearing in prompts or AI logs
These checks should only be included when the product actually uses AI features.
The Mandate for Certified Security Testing: The CREST Requirement
The Strict Prerequisite
CREST testing is not mandatory for every app listed on Atlassian Marketplace. The requirement applies when a vendor chooses Atlassian’s self-managed penetration testing route and wants the assessment recognised by Atlassian. In that case, Atlassian requires the testing company to be CREST accredited.
Before the engagement starts, vendors can use Atlassian’s penetration test scoping template to define the application and its attack surface. Atlassian also provides a Security Testing Starter Guide that can be shared with providers that need additional context about Marketplace frameworks. After the assessment, the results must be submitted to Atlassian for validation.
A CREST provider assessment can also count toward Atlassian Enterprise Certified when the required evidence is submitted for approval within the previous year.
Qualysec as Your Trusted Partner
For vendors choosing Atlassian’s self-managed testing route, the testing provider needs the right accreditation as well as a clear understanding of application security.
Qualysec is a specialised penetration testing company and a CREST-accredited provider. Its accreditation confirms that CREST has independently assessed its penetration testing capabilities against recognised technical and operational standards.
Beyond the accreditation itself, Qualysec has completed over 2500 penetration tests across SaaS, cloud, and API-driven applications, with assessments guided by certified testers holding credentials including CREST, OSCP, OSWE, and CEH. Its technique is manually guided instead of scanner-driven. Automated tools are utilized for coverage; however, manual investigation of permission flaws, business logic abuse, and cross-tenant problems—especially pertinent to Marketplace applications—is done by hand. Every reported result is also manually verified to exclude false positives.
That makes Qualysec relevant for vendors looking for CREST pentesting for Atlassian apps where the assessment needs to support Atlassian’s self-managed recognition route.
The Risks of Unaccredited Testing
Using a capable security provider does not automatically make the resulting report eligible for Atlassian’s self-managed program. If the provider lacks the required CREST accreditation, the findings may still help your engineering team, but Atlassian will not award program credit through this route.
Before appointing a provider, check its accreditation, understanding of Marketplace applications, proposed scope, reporting format, and retesting support. Doing this before the test starts helps avoid paying for an assessment that does not produce the evidence needed for the intended Atlassian program.
Step-by-Step Pentesting Process for SaaS Vendors
Step 1: Define the Marketplace App Architecture and Scope
Start by documenting the framework, supported Atlassian products, key features, routes, APIs, integrations, external domains, data handled, and any AI functionality. Atlassian’s scoping template also asks vendors to record major changes made since the previous security assessment, as these can affect what needs to be tested.
Step 2: Map Roles, Permissions and Tenant Boundaries
List the user roles that matter and prepare test accounts for each privilege level. Use at least two separate Atlassian tenants for isolation checks. Also document what each role should be allowed to do and identify sensitive Jira or Confluence objects that can be used during testing.
Step 3: Establish Rules of Engagement and Test Access
Before testing begins, agree on approved targets, restricted activities, and suitable testing windows. Give testers the credentials, API documentation, and architecture details they need. Also flag any rate-sensitive functions and make it clear which external systems are inside or outside the agreed scope.
Step 4: Perform Architecture-Specific Security Testing
Test the controls that matter for the app’s actual framework. Cover APIs, webhooks, and integrations as well as the main interface. Manual checks should probe privilege escalation, cross tenant access, authorization failures, and business logic abuse. Scanner findings should be validated before they are reported as exploitable issues.
Step 5: Validate and Prioritise Findings
Each finding should first be reproduced and checked against the affected role, tenant, endpoint, and component. For Atlassian submissions, Medium, High and Critical pentest findings must be recorded using CVSS 4.0 severity.
Step 6: Produce an Actionable Pentest Report
The report should make each issue easy to reproduce and fix. Record the affected component, endpoint, severity, technical cause, business impact, user or tenant context, reproduction steps, and supporting evidence. Where applicable, include CVSS details and clear remediation guidance. Atlassian expects findings to be verifiable and supported by actionable reproduction steps.
Step 7: Submit Applicable Findings Through Atlassian’s Process
The final PDF is not always the last step. For a recognised self-managed test, Medium, High, and Critical findings must be entered into Atlassian Marketplace Security, or AMS, and linked to the relevant ECOHELP request. Atlassian then uses those tickets to track the vulnerabilities and their remediation.
Step 8: Remediate Within Current Atlassian Timelines
Once Atlassian records a vulnerability in AMS, the fix deadline depends on its severity. Cloud apps now follow these remediation periods:
| Severity | Current Cloud App Remediation Time |
| Critical | 10 days |
| High | 4 weeks |
| Medium | 12 weeks |
| Low | 25 weeks |
Step 9: Retest the Remediation
Fixes still need to be checked. Retesting confirms that the original issue can no longer be exploited and that the change has not caused another problem elsewhere.
How Qualysec Helps You Pass Your Atlassian Security Reviews
For SaaS vendors preparing for an Atlassian review, Qualysec can support the self managed testing route as a CREST-accredited penetration testing provider. Atlassian requires this accreditation when a vendor wants a non-Bugcrowd assessment recognised under its program.
The scope can be built around the app architecture instead of using one fixed checklist. Forge, Connect, and mixed applications each place different parts of the attack surface under Atlassian or vendor control.
Qualysec can also organise findings in a way that makes them easier to act on and submit, including:
- Affected endpoint or component
- User and tenant context
- Severity and technical evidence
- Reproduction details
- Recommended remediation
- Retest status
Engagements are set up to follow Atlassian’s end-to-end procedure. Using CVSS 4.0, findings are rated Medium, High, and Critical. Therefore prepared to be submitted to AMS. For every problem, remediation advice is given along with developer help during repairs and a retest to verify that every exposure is fixed within Atlassian’s remediation windows. On request, a redacted sample report is provided so that suppliers can view the reporting style before committing.
Conclusion
A Marketplace penetration test should reflect how the app works with Atlassian accounts, permissions, customer data, and connected services. Forge reduces some infrastructure responsibility, while Connect leaves more of the stack with the vendor.
For teams working toward Atlassian Marketplace Security Compliance, independent security evidence is becoming more important as Atlassian expands its enterprise trust programs.
The value of testing comes from finding weaknesses early, fixing them properly, and having credible evidence that the app has been reviewed before enterprise customers rely on it.
Preparing for an Atlassian security review? Speak with Qualysec about a CREST accredited assessment suited to your app architecture.
FAQs
1. What is Atlassian Marketplace security testing?
It checks whether a Marketplace app meets Atlassian’s applicable security expectations and can withstand realistic attacks. Depending on the program, this can involve automated validation, penetration testing, and vulnerability management rather than a single security check.
2. Why does an Atlassian Marketplace app need penetration testing?
Marketplace apps can access permissions, APIs, customer data, and multiple tenants. Penetration testing helps uncover weaknesses in those areas before they are exploited. Enterprise customers may also ask vendors for independent testing evidence during procurement.
3. What does penetration testing for Atlassian Marketplace apps include?
Scope depends on the architecture. Testing may cover authentication, authorization, tenant isolation, APIs, webhooks, integrations, data handling, secrets, and business logic. Forge and Connect apps require different checks because they place security responsibilities in different areas.
4. What vulnerabilities can penetration testing identify in Atlassian Marketplace apps?
Testing can uncover broken access control, IDOR or BOLA, cross-tenant leakage, XSS, SSRF, injection flaws, OAuth weaknesses, exposed secrets, and business logic issues. The exact findings depend on the app’s design and integrations.
5. Is penetration testing required for Atlassian Marketplace apps?
Not for every Marketplace listing. Atlassian operates a formal penetration testing program, while Atlassian Enterprise Certified specifically requires evidence of a current annual penetration test completed through its Bugcrowd program or an approved CREST provider.
6. How often should an Atlassian Marketplace app be penetration tested?
Atlassian recommends annual or biannual testing, especially after major releases or significant code changes. Earlier testing may also make sense after migrations, new OAuth flows, major permission changes, new integrations, egress changes, AI features, or architectural updates.
7. What should an Atlassian Marketplace penetration testing report include?
A useful report should identify the affected component, severity, technical cause, business impact, affected role or tenant, reproduction steps and supporting evidence. It should also include remediation guidance, applicable CVSS information, and retest status where relevant.
