What to Check Before Installing an Atlassian Marketplace App

The question every security review eventually asks

Every enterprise procurement process for a new Jira or Confluence app eventually gets to the same question, usually from someone in security or IT, not the team that wants the app: where does our data actually go once this is installed? It’s not a box-ticking formality. It’s the single question that determines whether everything else about the app — its features, its price, how much the team likes it — even matters.

Why this question has gotten sharper

Third-party software risk isn’t an abstract worry anymore. Verizon’s 2025 Data Breach Investigations Report found that the share of breaches involving a third party jumped from 15% to 30% in a single year — the largest single-year shift the report has ever recorded. A marketplace app installed into your Jira or Confluence instance is a third party with access to your content, by definition. Security teams that used to treat “it’s just a small Marketplace app” as low-risk are increasingly right to stop treating it that way.

What actually gets checked

1. Where does the app run? This is the Forge-vs-Connect question, and it’s the biggest one. Apps built on Atlassian’s Forge platform run inside Atlassian’s own infrastructure — there’s no server the vendor operates that your content passes through. Apps built on the older Connect framework typically call out to infrastructure the vendor hosts themselves, meaning your Confluence pages or Jira issues get sent somewhere outside Atlassian’s security boundary just for the app to function. Neither framework is inherently disqualifying, but the answer changes what you’re actually trusting: Atlassian’s security posture, or a third-party vendor’s.

2. What permissions does it actually request? Atlassian shows the exact scopes an app asks for before install. A diagramming tool that requests admin-level user-management access, or a time-tracking app that wants to read every Confluence space regardless of project, is asking for more than its stated function needs — and that gap is worth questioning before approval, not after an incident.

3. Does it have an audit trail? If the app touches anything sensitive — credentials, PII, financial data — there should be a way to see what it found, when, and what happened to it. A security or compliance team that can’t produce a record of what a scanning tool actually caught over the last quarter can’t demonstrate ongoing monitoring, which matters well beyond any specific audit framework.

4. Can it be tuned to your environment, or is it one-size-fits-all? Generic detection rules catch generic problems. An app that lets you define your own patterns, exclude specific spaces or projects, or override default severity is one that can actually match how your organization is structured — not just a vendor’s assumptions about it.

5. Is the vendor honest about what it doesn’t do? A listing that promises to catch “100% of security risks” or makes similarly absolute claims is a bigger red flag than a narrower, accurately-scoped one. Security teams read marketing copy skeptically for good reason; specificity reads as more credible than superlatives.

Where Secret Sentinel lands on this

Secret Sentinel is built entirely on Forge — there’s no external server in the loop, and nothing ever leaves your Atlassian instance. It requests only the scopes its detection and redaction features actually need. Findings are logged with severity and timestamp (the Advanced edition adds a dedicated compliance dashboard for this), overrides are auditable per credential type or per space/project, and its own Marketplace listing describes exactly what it catches — 50+ specific credential types — rather than a vague promise to “stop all leaks.”

Install Secret Sentinel for Confluence · Install Secret Sentinel for Jira