Security

Last updated 24 August 2026

Koala’s security model is structural rather than procedural. The app runs entirely inside Atlassian’s infrastructure, holds two read-only permissions, has no way to make an outbound network call, and reads Jira only as the person looking at the chart.

This page describes how that works, exactly what is stored and for how long, how to report a vulnerability — and, just as importantly, what we do not claim.

The app has no network exit

Koala is an Atlassian Forge app. Forge permits an app to make outbound requests only to hosts its manifest explicitly declares. Koala’s manifest declares none — there is no external or remotes block — so there is no configuration, and no code path, in which the app can reach a Berry.Love server or any third party. Your Jira data is never transmitted outside Atlassian’s infrastructure.

Three independent layers hold that property:

The platform enforces it. Forge blocks any request to an undeclared host, regardless of what the app’s code attempts.
The manifest declares nothing. No egress permission exists to be exercised.
A test asserts it. The security-invariants suite checks that the source contains no external URLs and no calls to global fetch, and that the manifest declares no egress block. It is run before every deployment.

This is also the entry requirement for Atlassian’s Runs on Atlassian programme — no data egress, Atlassian-hosted storage only — for which Koala’s build is eligible.

Two scopes, both read-only

Scope	What it allows	Why Koala needs it
`read:jira-work`	Read-only access to issue data, and only through the viewing user’s own identity (`allowImpersonation`).	To count the issues a chart is configured to show.
`storage:app`	Read and write to Atlassian-hosted app storage.	To cache grouped counts, track background jobs, and hold schedules and their output files.

Koala requests no write scope of any kind. It cannot create, edit, transition, comment on, assign, or delete an issue. It has no access to Confluence, to user administration, or to any Jira surface beyond issue search.

Every read runs as you

Koala queries Jira exclusively through Forge’s asUser API, never asApp. Jira applies the viewing account’s own permissions to every page of every search, which means:

A chart can never show anyone a number derived from an issue their own Jira account could not already query.
Two people looking at the same dashboard gadget may legitimately see different totals. That is correct behaviour, not a bug.
Revoking someone’s project access immediately changes what their charts show, with no action required from us and no cache to purge.

An automated test asserts that asApp never appears anywhere in the app’s source.

One consequence worth stating plainly. A scheduled export runs as the person who created the schedule, at the scheduled time, whether or not they are logged in — that is what makes an unattended export possible. A schedule therefore inherits its owner’s permissions until they delete it. Schedules are private to their owner and are managed from the Schedules panel in the gadget footer.

What is stored, and for how long

Koala stores aggregates, not issues. A cached chart holds grouped counts and their labels — “Done: 412”, “In Progress: 87” — and never issue records, summaries, descriptions, comments, custom field contents, or attachments.

What	Retention	Visible to
Chart aggregate cache grouped counts and labels	15 minutes	The viewer who computed it
Background aggregation jobs progress and result records	24 hours	The user who triggered it
Scheduled run records and generated files	7 days	The schedule’s owner
Run history index	Most recent 30 runs	The schedule’s owner
Schedule definitions name, chart config, format, cadence	Until you delete them	The schedule’s owner
Gadget configuration chart type, group field, source	Stored by Jira with the dashboard	Per Jira’s dashboard permissions

A cleanup sweep runs every five minutes — Forge’s shortest available interval — and deletes anything past its retention window. Every storage key embeds the owner’s Atlassian account id, taken from the server-side request context and never from client input, and the app re-checks ownership before returning a job, an aggregate, or a downloaded file chunk. Automated tests assert both.

On-demand exports — the XLSX, PDF and PNG links in the gadget footer — are generated in your browser from the aggregate already on screen. They are never uploaded and never stored.

Koala stores no analytics or usage telemetry of any kind. There is nothing to opt out of.

Encryption and infrastructure

Is data encrypted in transit and at rest? Yes — by Atlassian. Every call the app makes to Jira goes over HTTPS through the Forge REST client, and everything the app persists goes into Forge’s managed key-value store, which Atlassian encrypts at rest. We name no algorithms, key lengths, or cipher suites, because they are Atlassian’s to specify and change — not ours to promise.

Because Koala holds no data outside Atlassian, encryption in transit and at rest, key management, network isolation, physical security, and data residency are properties of the Atlassian Forge platform rather than of anything Berry.Love operates. We implement no cryptography of our own, run no servers, and hold no copy of your data anywhere we could protect it differently. For the platform’s controls and certifications, see the Atlassian Trust Center.

We deliberately make no data-residency guarantee of our own: where Forge stores app data is Atlassian’s to determine, and we would rather say so than imply a control we do not hold.

Who can reach your data

Berry.Love is a one-person studio, so the honest answer is short. A single Atlassian developer account holds deploy rights to the app; there is no team, no contractor, and no support tooling with a view into customer sites. That account cannot read your Jira data — Forge gives a developer no impersonation ability outside the running app, and the app itself only ever reads as the person viewing a chart.

What the maintainer can see is Forge application logs for the app, used for debugging. Those logs contain job ids, account ids, timings, group-field names, and — when a Jira request fails — the error text Jira returned, which can include the search string that caused it. They do not contain issue summaries, descriptions, comments, or field values. Log retention is Atlassian’s, not ours. Two practical consequences: don’t put anything sensitive in a schedule name, and treat a JQL string as something that could surface in a diagnostic log.

Backups and recovery

Koala keeps no backups of its own — there is nowhere outside Atlassian for a backup to live. Almost everything in Forge storage is derived data: caches, job records and export files regenerate simply by viewing or re-running a chart. The one exception is your schedule definitions, which a storage loss would destroy and which you would need to recreate from the Schedules panel. Underlying platform durability is Atlassian’s responsibility.

Vulnerability management

Koala’s security properties are enforced as tests, not intentions. A dedicated security-invariants suite (npm test) is run before every deployment — there is no hosted CI; it runs on the maintainer’s machine — and asserts that:

Jira access never escalates to asApp.
Storage keys are owner-scoped, and job ownership is re-checked before any file chunk is served.
Group fields and JQL from a client payload are validated and bounded before they can reach a query or a storage key.
Only decimal ids are spliced into generated JQL, so a hostile value list cannot smuggle in a JQL fragment.
The source contains no external URLs and no calls to global fetch, and the manifest declares no egress block.

These assertions exist precisely because a future change might quietly violate one. When the egress check itself was found to be flawed in August 2026 — a comment-stripping bug meant it could pass on a real URL — it was repaired, and the repair was verified by planting a hostile URL and confirming the suite failed.

Dependency surface is kept deliberately small: six direct runtime dependencies — four Atlassian Forge SDKs plus pdf-lib and fflate for file generation — resolving to roughly 60 packages in the production tree, nearly all of them beneath the Forge SDKs. The lockfile is committed, so builds are reproducible. There are no telemetry SDKs, analytics packages, or HTTP clients anywhere in that tree. npm audit is run before every deployment and dependencies are reviewed when updated.

Fixes take priority over features. We aim to acknowledge a report within one business day and to ship a fix for a confirmed exploitable issue as quickly as we can validate it. Forge deployments reach every installation directly — customers never have to perform an upgrade to receive a security fix.

Remediation targets

We aim to acknowledge a report within one business day, confirm or dismiss it within five, and ship a fix for a confirmed issue within seven days for a critical or exploitable finding and thirty for anything lower. Forge hosts a single deployed version, so a fix reaches every installation at once — there is no customer upgrade to coordinate and no long tail of unpatched installs.

If something goes wrong

No incident affecting customer data has occurred to date. Should one occur, we would notify the administrators of affected sites by email, and Atlassian through the Marketplace partner channel, within 72 hours of confirming it — with what happened, what data was involved, and what we have done about it. We would rather tell you about a near miss than have you learn about a real one elsewhere.

Reporting a security issue

Email support@berry.love with “Security” in the subject. Please include what you found, how to reproduce it, and what impact you believe it has.

Machine-readable contact details are published at /.well-known/security.txt.

We ask for a reasonable opportunity to fix an issue before it is published. In return, we will not pursue legal action over good-faith research that respects customer data, avoids privacy violations and service disruption, and stays within Jira sites you are authorised to test. We do not run a paid bug bounty, but we are glad to credit reporters who would like it.

What we do not claim

An honest account is worth more than a longer list of badges, so here is the other side of the ledger.

Berry.Love is a small independent studio. Koala holds no SOC 2, ISO 27001, or equivalent certification, and has not undergone an independent penetration test. Its security posture rests on the platform it runs on and on how narrowly it is built — not on an audit.
We run no paid bug bounty programme.
We publish no uptime SLA. Availability is Atlassian’s; we operate no servers of our own.
The hash used to key the chart cache is FNV-1a, a fast non-cryptographic hash. It is a cache key, not a security control — access is enforced by the account id embedded in the storage key, never by the hash.
Schedule names and failing search strings can appear in Forge application logs, which the maintainer can read while debugging — see who can reach your data. Please don’t put anything sensitive in a schedule name.
Koala implements no uninstall purge handler of its own; removal of app storage on uninstall is handled by the Forge platform.
There is no self-service data export or deletion endpoint. Requests under GDPR or comparable regimes go to support@berry.love and are handled by hand.

This website

koala.berry.love is a set of static files. It runs no JavaScript — view source and check — sets no cookies, and loads nothing from a third party: no analytics, no fonts, no tag managers, no embedded widgets. It is served over HTTPS with HSTS, a restrictive Content-Security-Policy, X-Content-Type-Options: nosniff, and X-Frame-Options: DENY.

Revisions

This page is revised whenever a change alters something stated on it. Corrections are made visibly rather than removed quietly.

24 August 2026 — first published.

Questions

Security questions, vendor review questionnaires, and procurement forms all go to support@berry.love and are answered by the developer. See also the privacy policy, which covers what the app does with your data.