Security

Effective 10 September 2026. This page describes how the Atlassian Marketplace apps published by Two Little Moons Consulting (ABN 49 732 400 198, Australia) are built, hosted and operated: Honest Timesheets for Jira, Pivot Reports for Jira, Tickbox Checklists for Jira, Mailpost for Jira, Agile Gadgets for Jira, Git Links for Jira, Stencil Issue Templates for Jira, Status Clock: Time in Status & SLA for Jira, Countersign: Approvals & Sign-off for Jira, Ditto: Bulk & Deep Clone for Jira, and Slide Rule: Calculated Fields for Jira.

What you can rely on

Everything below is a fact about how the apps are built, and each is verifiable — by Atlassian's own badge, by the app manifest a site administrator can read, or by the consent dialog Atlassian shows you. Nothing on this page is a claim you have to take on trust.

Where the apps run

Every app runs entirely on Atlassian Forge, inside Atlassian's own infrastructure. We operate no servers, no databases and no hosting of any kind. There is no environment we could log into that holds your data, because no copy of your data ever leaves Atlassian's platform for a system of ours.

This is the single most important fact about the security of these apps, and it is a property of the architecture rather than a promise about our conduct. Data residency follows your Atlassian site.

Authentication and authorisation

Apps call Jira as the person using them, so your own Jira permissions apply to everything they read and write. Where an app must act on its own authority — a scheduled sweep, a background trigger, a workflow validator that has no signed-in user — it re-checks the acting person's permission before doing anything on their behalf, and the privileged path is kept as narrow as the feature allows.

Apps request the smallest set of Atlassian scopes their features need. Each app's scopes and the reason for each are stated on its Marketplace listing.

Data at rest

Where an app stores state, it uses Forge hosted storage, which Atlassian encrypts and isolates per installation, or Jira entity properties on the issue itself so the values are searchable with JQL. What each app stores is itemised in the privacy policy. Uninstalling an app deletes its Forge storage.

Credentials that an administrator supplies — an email provider key, a Git host token — are held in Forge secret storage. They are never displayed after entry, never written to logs, and never sent anywhere other than the service they authenticate to.

Data in transit and outbound connections

Nine of the eleven apps make no network calls outside Atlassian at all and are eligible for Atlassian's Runs on Atlassian designation. They cannot contact an external host, because they declare no permission to do so.

Two apps connect outward, in both cases only to a service the customer chooses and configures:

All connections use TLS. No app contacts any analytics, telemetry or advertising service.

How the apps are built

Each app is developed against automated tests that assert behaviour rather than implementation, and every release passes, before deployment: a unit-test suite covering the logic that produces user-visible numbers, browser-level end-to-end tests, at least two independent code reviews, and a dedicated security review looking specifically for authorisation defects, cross-tenant data exposure and unsafe handling of user-controlled input. Findings are fixed before release and pinned by a regression test.

Dependencies are kept few and current. The apps ship no third-party analytics, tracking or advertising code.

Access to your data by us

The apps are published by a sole trader; a single person maintains them. That person has no standing access to any customer's Jira data — there is no administrative console, no support impersonation and no database to query, because the apps hold nothing outside your own Atlassian installation. Forge invocation logs, which contain timestamps, HTTP status codes and error messages rather than issue content, are visible to us only if your site administrator chooses to share them.

Reporting a vulnerability

Email support@twolittlemoons.com with "Security" in the subject. Please include enough detail to reproduce the issue. We aim to acknowledge within 3 business days and to keep you informed until it is resolved. We will not pursue or support legal action against anyone who reports a genuine vulnerability in good faith, gives us reasonable time to fix it, and does not access, modify or destroy data belonging to others while investigating.

If an incident affects customer data, we will notify affected site administrators and Atlassian promptly, with what happened, what was affected and what to do about it.

What we do not claim

We would rather be useful than impressive, so these are stated plainly:

If your procurement process needs something listed here that we do not have, tell us — it is better to know than to have you assume either way.

Changes

We will update this page and its effective date when any of the above changes. A new outbound connection, or a new category of stored data, is announced in the app's release notes before it ships.