Security policy

Architecture and hosting#

Dealtrail CRM is built entirely on Atlassian Forge, in UI Kit (not Custom UI), so its interface is rendered by the platform itself, not by code we serve. It has no servers, databases or infrastructure of its own: it stores no data outside Atlassian, and its manifest declares no permission to make an outbound network call to anything other than Atlassian's own APIs.

Transport security, encryption, physical security and patching of the underlying platform are Atlassian's responsibility, covered by Atlassian's own compliance programme for Forge.

Data we handle#

The app handles the records your users type in. It reads a Jira work item's summary and status live when a user links one or views a linked record, and people's names to display. The only thing it writes to Jira is its own four read-only custom fields, on work items linked to a record. Full detail on what is and is not kept is in the privacy policy.

Authentication and access control#

There is no independent login system. Every request runs as the signed-in Jira user, authenticated by Forge through their existing Jira session. We never collect, transmit or store Atlassian usernames, passwords or API tokens.

Inside the app there are no roles: anyone who can open it can read and change every record (see Permissions and access). The exceptions are workspace settings, Load Sample Data and Delete All Data, which the server only accepts from a user who holds Jira's site ADMINISTER permission, checked on every save. Access is bounded by the scopes declared in the manifest:

Jira reads are made as the signed-in user (asUser), so Jira's own permissions apply. The exception is the app's own read-only custom fields: only the app can write them (asApp), so those writes and the lookups they need run as the app. Jira Automation actions run the same server code as the screens, as the person on the rule's connection, check that this person can see the work item, and refuse to run on an inactive licence.

Input handling#

Every server function validates what it receives before using it: record ids must be well-formed UUIDs, text is trimmed and length-limited, choices (stages, statuses, sources, ratings, reasons, currencies) are checked against fixed lists, numbers must be finite and non-negative, and account ids and Jira work item keys must match strict patterns. Saved-view filters are limited to a fixed set of keys. CSV exports neutralise cells that a spreadsheet would run as a formula. The app was reviewed against the OWASP list of common weaknesses and hardened where needed.

Reporting a vulnerability#

Email security@vudia.site with what you found, the steps to reproduce it, and which part of the app it affects. Please do not publish details until we have had a chance to fix it. For general support, use info@vudia.site.