Security Policy — Converse for Confluence and Jira

Vendor: Churrie Works Inc.
App: Converse for Confluence and Jira
Hosting platform: Atlassian Forge
Last updated: May 2026

This policy describes how Converse for Confluence and Jira protects customer data, the security controls inherited from the Atlassian Forge platform, and how to report security issues to us.

1. Hosting model and shared responsibility

Converse for Confluence and Jira is a Forge cloud app. It runs entirely inside Atlassian's hosted Forge runtime, which means:

  • No vendor-operated servers, databases, or backend services touch customer data. All compute and storage is provided by Atlassian as part of the customer's Atlassian Cloud subscription.
  • All data stored by the app lives inside Atlassian's infrastructure — Forge Key-Value Store (KVS), Confluence content properties, Confluence child pages, and Jira app properties. None of this data leaves the customer's Atlassian Cloud region.
  • Atlassian is the primary processor for all data the app handles. Churrie Works Inc. operates as a sub-processor by virtue of writing the application code that runs inside Atlassian's runtime.

This shared responsibility model means the app inherits Atlassian Forge's security posture, including SOC 2 Type II and ISO 27001 certifications maintained by Atlassian. See Atlassian Trust Center for Atlassian's compliance attestations.

2. Data the app processes

The app processes only data that already exists in the customer's Atlassian Cloud tenant or that users explicitly enter into the app's UI. We process:

  • Atlassian account IDs — opaque identifiers for users (e.g. authors of conversations and replies, mention recipients, read-tracking).
  • Conversation and reply content — text and HTML that users type into the app's UI.
  • @mention account ID lists — to deliver in-app notifications.
  • User preferences — notification routing, hub-list pin order, category filters.
  • Read-tracking timestamps — to power "unread" indicators in list views.
  • Jira issue keys (Tier 2 and above) — when users link or create Jira issues from a conversation.
  • Signal payloads (Tier 3) — when users create directives or signals in the Align edition.

We do not process:

  • User email addresses (the app never reads or stores email addresses, even though read:confluence-user could return them — we only request display names and avatar URLs at render time).
  • IP addresses (Forge does not expose request IPs to apps).
  • Browser fingerprints, cookies, or any tracking identifiers (the app sets none).
  • Health, religious, political, or other special-category personal data (GDPR Article 9). If a user types such data into a conversation body, that is their input and falls under Atlassian Cloud's processing terms.

A complete data inventory with field-level detail is published in the app's privacy and data residency document (see source: docs/PRIVACY-AND-DATA-RESIDENCY.md in the public repository).

3. Encryption

  • In transit: All data exchanged between the app's UI and Forge resolvers, and between Forge and Atlassian REST APIs, travels over TLS 1.2+ provided by Atlassian's infrastructure. The app does not establish unencrypted connections to any host.
  • At rest: All Forge KVS data, Confluence content properties, and Jira app properties are encrypted at rest by Atlassian per the Atlassian Cloud Security Practices.
  • Application secrets: Internal app secrets (the Confluence↔Jira KVS bridge shared secret and the inbound Jira webhook shared secret) are stored using Forge's --encrypt variable storage. Forge encrypts these values at rest and decrypts them only inside the app's function runtime. They are never logged or exposed in the app's UI.

4. Authentication and access control

  • End-user authentication is handled by Atlassian Cloud. The app inherits the user's authenticated session — the app itself never asks users for passwords, Personal Access Tokens (PATs), or any other shared secret.
  • Per-API authorization is enforced by Atlassian's Forge platform against the scopes declared in the app's manifest. The app declares 17 scopes; each one is justified in the public scope-justification document. The minimum scope necessary for each operation is used.
  • Per-resource permission checks are performed before reads and writes: Confluence page-permission checks (via read:confluence-content.permission) ensure that users only see threads on pages they can view, and only edit threads on pages they can edit. Cross-product reads (e.g. conversation reads from the Jira issue panel) re-verify the user's Confluence permission server- side, never just in the UI.
  • Tier (license) enforcement is performed on the server side. Every Jira- facing resolver and every Tier-3 (Align/Signals) resolver re-checks the customer's Marketplace edition before executing the request. Display conditions in the manifest control UI visibility, but they are not the primary enforcement boundary — the resolvers are.

5. Cross-product communication (KVS bridge)

The app spans Confluence and Jira partitions of the same Atlassian Cloud tenant. Because Forge isolates KVS by product partition, the app exposes one Forge web trigger in the Confluence partition that the Jira partition can call to read its own (Confluence-side) KVS data. This cross-partition mechanism is hardened as follows:

  • Shared-secret authentication: Every request to the bridge web trigger must include a X-Converse-Kvs-Secret header containing the value stored in the CONVERSE_KVS_BRIDGE_SECRET Forge variable. The secret is unique per install and never shared with customers.
  • Timing-safe comparison: The bridge compares the inbound secret using crypto.timingSafeEqual to defeat timing-based brute-force attacks.
  • Header-only secret transmission: The secret is only sent in the request header. It is not duplicated in the request body and is never logged.
  • Authenticated source URL: The bridge URL is stored as a Jira app property on the customer's Jira tenant, scoped to the same Atlassian account that owns both partitions of the app. It is not exposed to customer users.

The same hardening is applied to the inbound Jira webhook (X-Converse-Jira-Secret header, crypto.timingSafeEqual comparison).

6. Logging and monitoring

Application logging is performed via Forge's logger channel only. Logs are managed by Atlassian per the Atlassian Cloud logging retention policy. Churrie Works Inc. does not ship logs to third-party log aggregators, error trackers, or analytics services.

The app applies PII-redaction to its log statements:

  • Atlassian account IDs are masked to the last 8 characters (forgeDebug.accountIdSuffix) — sufficient for diagnostic correlation, insufficient to identify a specific user out of a global pool.
  • KVS keys that embed account IDs have the identifying tail replaced with a SHA-256 truncated hash; the key prefix is retained to identify the data shape.
  • Conversation and reply body content is never logged in any code path.
  • Application secrets (KVS bridge secret, Jira webhook secret) are never logged on either client or server side.
  • Confluence error response bodies are truncated to 240 characters when an upstream call fails — sufficient for diagnostics, insufficient to capture full PII payloads from upstream errors.

Verbose logDebug / logAlways output is gated by an environment variable (CH_DEBUG_LOGS=1) and uses DEBUG level in Forge logs intended for development only; production deployments leave this off.

7. Incident response and breach notification

If Churrie Works Inc. becomes aware of a security incident affecting the app or its data, we will:

  1. Triage the incident within 24 hours of detection.
  2. Apply containment and mitigation steps coordinated with Atlassian's Forge platform team where applicable.
  3. Notify affected customers via the email address on file in their Marketplace subscription within 72 hours of confirming a personal-data breach, in alignment with GDPR Article 33 and customer contractual obligations.
  4. Coordinate with Atlassian on platform-level disclosure if the incident originates from or affects the Forge runtime itself.

Customers can report observed incidents to security@churrieworks.com.

8. Vulnerability disclosure policy

We welcome reports of suspected security vulnerabilities in the app. We commit to:

  • Acknowledging receipt of vulnerability reports within 2 business days.
  • Triaging reports within 5 business days and providing an initial severity assessment.
  • Coordinating a fix and disclosure timeline with the reporter, prioritizing critical issues for same-week patches where feasible.
  • Crediting reporters in release notes if they wish to be acknowledged publicly. We do not currently operate a paid bug-bounty program.

How to report: email security@churrieworks.com with:

  • A description of the vulnerability and the affected feature.
  • Steps to reproduce.
  • Any proof-of-concept artifacts (screenshots, payloads, code).
  • Your preferred disclosure timeline and whether you wish to be credited.

We ask that reporters refrain from public disclosure until a coordinated patch is available, and that testing be performed in a way that does not affect customer data or service availability.

9. Compliance and certifications

App-level certifications: Churrie Works Inc. does not currently hold independent SOC 2, ISO 27001, HIPAA, or similar attestations for this app.

Inherited platform certifications: All app processing happens inside the Atlassian Forge runtime, which is covered by Atlassian's own certifications including SOC 2 Type II and ISO 27001. See Atlassian Trust Center for the current list and audit reports.

Privacy regulations:

  • GDPR: Churrie Works Inc. operates as a data processor (sub-processor to Atlassian) for personal data flowing through the app. The customer's organization is the data controller. Data subject access requests, including right of erasure, are served via the standard app UI and Atlassian's platform-level GDPR account-deletion event flow — see the privacy and data residency document for details.
  • CCPA: When the app is used by customers who qualify as CCPA "businesses", Churrie Works Inc. operates as a service provider for that customer's end-user data.

Data residency: The app does not select or override the storage region for any data. All data follows the customer's Atlassian Cloud region (US, EU, etc.). Churrie Works Inc. cannot independently support data residency selection while the underlying Atlassian-managed storage layers do not expose region selection to Forge apps.

10. Data Processing Agreement (DPA)

Churrie Works Inc. relies on Atlassian's master Cloud Data Processing Addendum, which extends to Forge apps as sub-processors per the Atlassian Marketplace Partner Agreement. We do not currently offer a separate vendor-specific DPA for self-service customers.

Enterprise customers who require a vendor-specific DPA may request one via security@churrieworks.com. We will provide a customized DPA on request, typically based on the IAPP / IAB DPA model.

11. Sub-processors

Beyond Atlassian, this app introduces no additional sub-processors. The app does not use third-party analytics, error tracking, content delivery networks (other than Atlassian's), email senders, or external APIs. The app's external egress allow-list (permissions.external.fetch.backend in the app manifest) is restricted to:

  • *.atlassian-dev.net — Forge web trigger URLs (cross-partition KVS bridge)
  • *.atlassian.net — reserved fallback to a tenant's primary Atlassian site host

12. Contact

This policy is published at https://churrieworks.com/docs/converse/security-policy.html and reviewed at minimum annually, or whenever the app's security posture materially changes.