Security Policy

Reporting a vulnerability — quick reference Email support@ux-software.com with subject prefix [security]. We acknowledge within 2 business days. Please do not disclose publicly until we have shipped a fix. See Reporting a vulnerability for full details.

This page describes how to report a security vulnerability in any UX Software product, what response you can expect, and the security practices we follow when building and operating those products.

It is the company-wide security policy applicable to all UX Software products, including Atlassian Cloud Forge apps, Atlassian Data Center plugins, and any future software products distributed through the Atlassian Marketplace or directly.

For data-handling specifics — what data each product processes, where it is stored, retention windows — see the Privacy Policy together with each product's Data Security Statement.

Contents

  1. Reporting a vulnerability
  2. What you can expect from us
  3. Scope
  4. Safe harbor
  5. Security practices we follow
  6. Compliance and certifications
  7. Acknowledgments
  8. Changes to this policy
  9. Contact

1. Reporting a vulnerability

If you believe you have found a security vulnerability in any UX Software product, please report it to us privately so we can investigate and fix it before it is disclosed publicly.

  • Email: support@ux-software.com
  • Subject prefix: [security]

When you report, please include:

  • The product, version, and environment (Cloud Forge / Data Center / version number) where the issue was observed.
  • A clear description of the vulnerability and its potential impact.
  • Steps to reproduce (proof-of-concept code or screenshots are welcome).
  • Your name and contact details, and whether you would like to be credited in the Acknowledgments section below.

Please do not:

  • Disclose the vulnerability publicly before we have had a reasonable opportunity to investigate and remediate.
  • Test against customer environments other than your own.
  • Engage in social engineering of UX Software staff or our customers' staff.
  • Attempt to access, modify, or destroy data that does not belong to you.
  • Use the issue to extract or exfiltrate data.

2. What you can expect from us

We aim for the following response targets when you report a vulnerability in good faith. These are best-effort commitments, not contractual SLAs.

StageTarget
Acknowledgement of receipt 2 business days
Initial triage and severity assessment 5 business days
Fix or mitigation plan communicated to you 15 business days for High / Critical severity; 30 business days for Medium / Low
Public disclosure (with reporter credit if desired) After fix is shipped, at a coordinated date

If a fix requires more time than these targets, we will keep you updated on progress.

3. Scope

In scope: any product distributed by UX Software (current and future) — including Webhooks Pro for Jira Cloud, the Jira Webhooks Plugin for Data Center, and any other Atlassian Marketplace product released by UX Software.

Out of scope:

  • The Atlassian platform itself (Forge runtime, Atlassian SQL / KVS, the Atlassian Marketplace site). Report Atlassian-platform vulnerabilities to Atlassian via their Trust Center.
  • Customer-configured webhook receivers (URLs the customer's administrator chose to send data to). Report those to the customer or to the operator of the receiver.
  • Issues that require physical access to a customer's infrastructure.
  • Reports of missing security headers, missing best-practice hardening on ux-software.com marketing pages, or other marketing-website issues that do not affect the products themselves.
  • Self-XSS, social engineering, denial of service via volumetric attacks.

4. Safe harbor

We will not pursue legal action against, or interfere with, any security researcher who:

  • Engages with us in good faith under this policy.
  • Limits their testing to scope listed above.
  • Does not access, modify, or destroy customer data.
  • Reports the vulnerability privately and gives us reasonable time to fix it before any disclosure.

If your activities are consistent with this policy, we consider them authorised under the Atlassian Marketplace partner agreement and applicable computer-misuse laws.

5. Security practices we follow

Development

  • Secure SDLC. Every change goes through code review before merge. Production changes require a passing CI build.
  • Dependency scanning. Production dependencies are tracked in package-lock.json and audited. Critical CVEs in dependencies are patched on next release; high-severity CVEs are patched promptly.
  • No secrets in source. API tokens, signing keys, and customer-supplied secrets never appear in source control. We use Forge environment variables (forge variables set) and Forge KVS / SQL for secret storage.
  • Type-checked code. All TypeScript code passes tsc --noEmit in CI before deployment.

Runtime (Cloud Forge products)

  • Sandboxed execution. Forge enforces app-level sandboxing and an explicit scope model in the manifest. Our products declare only the minimum scopes they need.
  • Per-host egress approval. Forge requires the installing admin to approve every outbound destination. We declare external.fetch.backend: "*" in the manifest, but no request reaches a host that the customer's admin has not approved.
  • No telemetry, no analytics. Our products contain no third-party analytics, no error trackers, no session replay. No data is reported back to UX Software except through support emails the customer chooses to send.
  • TLS by default. All outbound HTTP requests to customer-configured destinations use HTTPS unless the customer's administrator explicitly configures an HTTP destination.
  • HMAC signing. Where supported (e.g. Webhooks Pro), customers may sign outbound payloads with HMAC-SHA-256 secrets stored inside the platform.

Runtime (Data Center products)

  • Customer-controlled environment. All runtime data stays inside the customer's own Jira / Confluence database. UX Software has no access.
  • Atlassian Marketplace security baseline. Our Data Center products comply with Atlassian's security requirements for Data Center apps, including CSRF protection, XSS protection, strict input validation, and integration with Jira's outbound Allowlist.

Operational

  • Marketplace-only distribution. Customers receive code exclusively through the Atlassian Marketplace upgrade mechanism. We do not ship code through any other channel.
  • No production access by employees. UX Software employees do not have access to customer environments. Support requests are handled with information the customer voluntarily shares.
  • Incident response. In the event of a confirmed security incident affecting customer data, we will notify affected customers via the Atlassian Marketplace listing's release-notes channel and (where available) by email to the billing contact on file, within 72 hours of confirmation, in line with GDPR Art. 33 timeframes.

6. Compliance and certifications

  • All Cloud products run on the Atlassian Forge platform; the platform's own certifications (SOC 2, ISO 27001, etc., as declared by Atlassian) cover the underlying infrastructure.
  • We participate in Atlassian's Cloud Fortified programme where eligible.

7. Acknowledgments

We thank the following researchers for responsibly disclosing vulnerabilities to us:

None to date — we will list contributors here, with their permission, after the first responsible disclosure is received and remediated.

8. Changes to this policy

Material changes are reflected in the Effective date at the top. The current version is always available at ux-software.com/security.html.

9. Contact

Email: support@ux-software.com (subject prefix [security])

UX Software uses cookies to ensure you get the best experience on our website. More information ok