Security — Outlier

A security policy for an app with no servers is a shorter document than the phrase suggests, and pretending otherwise would be the first thing wrong with it. Outlier runs entirely inside Atlassian's platform. There is no backend of ours, no database of ours, no network of ours, and nothing to breach that is not Atlassian's own infrastructure. What follows is what that means in practice, what is checked before anything ships, and what to do if you find something.

This page is about how the app is built and operated. The privacy policy covers what is read, stored and kept, and for how long, and the method page prints the whole arithmetic.

Last reviewed: 2026-09-18.

What you can verify without trusting us#

Most security claims about an app have to be taken on faith, because the source is not public. One does not, and it is the one that matters most.

The Forge manifest, which Atlassian shows you on the consent screen. It either declares an external host, an egress domain or a Forge remote, or it does not. Outlier declares none of them, and no web trigger — no public endpoint of ours exists to be called. That is not a promise about our intentions; it is a property the platform enforces, and you can read it before you click install.

The manifest also declares one relaxation, and it is better read here than discovered there: content.styles: unsafe-inline, which permits the inline styles React writes inside the app's own iframe. It does not loosen what scripts may run or what the page may connect to.

Atlassian's Runs on Atlassian badge certifies a narrower thing than it sounds like, so it is worth stating precisely: it is awarded by measuring the app rather than by asking us, and it means the app uses Atlassian-hosted compute and storage. It permits an app to send data out for analytics; this one sends nothing out at all.

Everything else on this page is a claim about work we do, and is written to be specific enough to be argued with.

Where the data lives#

Forge storage, and nowhere else. It follows your site's realm automatically, which is what qualifies the app for PINNED data residency status without any configuration on your part. Storage belongs to your installation: nothing the app keeps is shared between one customer's site and another's.

One distinction is worth making because a review will ask about it. Storage residency and compute location are not the same guarantee. Atlassian's own documentation says Forge may occasionally execute an invocation from a location other than the host product's. So the honest sentence is that the data resides where your site does, while an invocation may sometimes run elsewhere — and since nothing leaves Atlassian, what could run elsewhere is Atlassian's infrastructure rather than a vendor's.

What is read, and what is kept#

The app asks Jira for three fields — created, updated and status — and for the issue's changelog. The changelog is the part that cannot be narrowed: Jira's changelog endpoint takes no field filter, so a summary or description edit arrives with its old and new text, and every entry names the person who made it. All of that is read and dropped in the one function both read paths share, before anything is derived and before anything is written.

The honest sentence is therefore that the app reads only how tickets moved — not that content is never sent to it. The second would be easy to disprove with a proxy; the first survives being checked.

What is kept is issue keys, status ids and timestamps, plus the board's own settings: its id, its filter, the labels and work types it narrows by, its timezone and its working week. There is no field named for a person anywhere in the schema, and every write is refused by name, at any depth, if one appears. That guard reads field names rather than values, which is why the sentence above is about what the app asks for and not only about what the guard catches.

When the app is uninstalled it deletes its own rows in a preUninstall handler, rather than leaving them to the twenty-eight days Forge would otherwise hold them. That handler has a deadline it may not meet: on a large installation it deletes the most revealing rows first, records what it could not reach, and whatever is left falls under Forge's own twenty-eight-day window. "We deleted everything" and "we deleted what we could in the time we were given" are different claims, and only the second can be made honestly by a function with a budget.

An administrator has no button for deleting one card's data on its own. What exists is uninstalling, and the app's own forgetting: a board nothing reads - no dashboard opened and no rule asking for its morning - stops being collected after thirty days and is deleted after ninety.

Whose eyes the data is read with#

Every read of Jira that a person or their Automation rule triggers — the card, the configuration screens, the admin page, the Automation step — is made as that person. And it is not left to Jira to answer emptily: before any stored data is handed back, the app asks Jira for the board's configuration as the reader, and a refusal there becomes a named "you cannot see this board" state rather than a number.

The app reads as itself in two places only: the hourly collection, and the one-off walk of a board's history when a card is first configured. Neither has a user to act as.

There is one exception, and naming it is cheaper than having it found. The inventory of cards this installation holds is read as the app, because the question — which cards exist here — has no board to check against. A card on a board you cannot open still appears in that list, showing its ids and when it was first seen; its board name, filter name and labels are blank, because those come from a request made as you.

The app asks for granular scopes rather than the single classic read:jira-work scope. The list is longer to read, and that is the point: the classic scope would grant comments, attachments and worklogs the app never touches. A few entries look wrong for a product that reads nothing about people — read:user, read:group, read:avatar, read:audit-log. They are there because Jira requires each endpoint's scopes as a complete set, and four endpoints between them account for every entry that looks wrong. Reading one field of a saved filter takes nine of them, read:user and read:group among them. Searching the work in flight takes five, one of which is read:audit-log. Counting the same search — a different endpoint from running it, with a different set — takes read:field, read:field.default-value and read:field.option, none of which the search itself asks for. And asking a board how its columns are arranged takes read:board-scope.admin, which is the only scope Atlassian publishes for that endpoint: there is no reader's variant of it to ask for instead. The app reads no user, no group, no avatar and no audit log, administers no board, and writes nothing anywhere.

What is checked before anything ships#

Two of these are gates that fail the build. Two are steps somebody performs, and they are marked as such, because a check somebody remembers to run is not a control and calling it one would be the same overstatement this page is trying to avoid.

• Gate — dependencies are scanned on every push, across both workspaces, and the build fails at moderate severity or above.
• Gate — the manifest's scopes are held to what the app's endpoints accept, in both directions: an endpoint missing a scope fails, and so does a scope no endpoint needs. The build also holds every read a person triggers to the acting user. Both of those were verified by mutation — deliberately breaking them to confirm the build goes red — because a green test is not evidence that a test catches anything.
• Step — the vendored scope table is re-checked against Atlassian's published API descriptions by hand before scopes are changed. It reaches the network, so it does not run in the build.
• Step — the built bundles are read before a release, not only the source: no network call of ours, no markup built from strings, no eval.

What the vendor can see#

Application logs. They carry counts, durations, the shapes of endpoints called and the names of fields — never ticket content, never a query, never a person. Endpoint paths have any segment containing a digit removed before they are logged, so a ticket key cannot arrive that way. Three of the app's eighteen logging statements do print one value: the id of the card a failure belongs to, which begins with a board id. That is a deliberate trade — a failure nobody can attribute to a card is a failure nobody can fix — and it is the only customer value the app writes to a log.

Logs are retained by Forge on Atlassian's schedule. Nothing is exported and nothing is kept beyond it.

What can leave your site, and who decides#

Nothing leaves Atlassian because of the app. Two features let you send something out, and both are yours to switch on:

The Automation step. The app can answer an Automation rule with this morning's text. What the rule then does with it is the rule's business — if it posts to Slack through a "Send web request" action, that is your rule, your schedule, your channel and your credentials. The app has no destination of its own and cannot acquire one without a new manifest you would have to consent to.

Ask Rovo why. Where your site has Rovo, the card offers a button that hands the card's own text to Rovo as a question. It appears only if the platform says your reader has Rovo, and it runs in your instance, on your credits, when somebody presses it. No model is deployed by this app and none is called on its behalf.

Who can deploy, and what stops them#

Worth stating because this page also claims a deploy is the fastest way to contain an incident: the same property is the app's most valuable asset. A Forge deploy reaches every installation with no action by you.

Production deploys are made by hand and are not automated from the repository. The deploy credential exists in exactly one continuous-integration step, and that step installs dependencies with lifecycle scripts disabled, so a compromised package cannot run code in the one place a token is in reach. The step that runs the tests installs normally and holds no credentials at all.

Reporting a vulnerability#

Write to support@chmut.com. Say what you found and how to reproduce it; you do not need a proof of concept for us to take it seriously. You will get a human reply within three working days, which is a commitment about acknowledgement rather than about a fix.

You can also report it to Atlassian, who will raise it in their Marketplace Security project, where it arrives with a remediation due date. Either route reaches the same person.

These are the timeframes the app is held to, and they are Atlassian's rather than ours:

If there is an incident#

A documented response plan exists and is kept with the code rather than in somebody's head. Its commitments, in order of the clock:

• Atlassian is notified within 24 hours of becoming aware, as a P1.
• Updates go to Atlassian no less than every six hours while it is open.
• Affected customers are notified within 72 hours of identification.

Containment here is unusually direct. A Forge deploy reaches every installation without any action by you, so rolling back to the last good revision is both the fastest response available and a complete one — there is no upgrade for an administrator to apply and no site left behind on a broken build.

What this page does not claim#

A short list, because a security page that only lists strengths is a marketing page.

Outlier is built and maintained by one person. There is no rota, no around-the-clock monitoring, nothing watching the logs for anomalies, and no second pair of eyes on a change — discovery of a problem would come from a customer, from Atlassian, or from looking. The incident response plan is written and has never been exercised. The app holds no compliance certifications, has not been penetration-tested by an external vendor, and does not run a bug bounty programme. Dependency scanning is the only automated security scanning in the build; there is no static analysis and no dynamic testing. Application logs live on Atlassian's retention schedule rather than a year of our own, which would make a late-discovered incident harder to reconstruct.

None of that is a reason to distrust the app; it is the shape of a small product, and you are entitled to know it before you install one.