Security Overview

Authentication & Authorization

Collabound uses industry-standard authentication and authorization mechanisms to protect access to the platform:

• Email and password login — The Collabound Portal uses account registration, email activation, password login, password reset, and account lockout controls for Portal users.
• JWT and rotating refresh tokens — After authentication, Portal sessions are managed using short-lived JSON Web Tokens (JWT) and rotating refresh tokens. Token reuse detection and explicit revocation help protect active sessions.
• Forge app assertions — Communication between the Collabound app in Jira and the Collabound service is authenticated with Forge Invocation Tokens and Collabound app assertion JWTs. Site binding additionally requires a short-lived bind code generated from the Portal.
• Role-Based Access Control (RBAC) — All user actions are governed by workspace-level roles with scoped permissions. Roles determine what a user can view, share, configure, and administer. Permissions are enforced at the API level, ensuring consistent access control regardless of the client interface.

Data in Transit

All communications between Collabound components are encrypted in transit:

• All API calls between the Collabound app in Jira and the Collabound service are transmitted over HTTPS with TLS encryption.
• All requests between the Collabound Portal (web browser) and the Collabound service use HTTPS/TLS.
• Internal service-to-service communication within the Collabound infrastructure is encrypted using TLS.
• Modern TLS versions and cipher suites are enforced. Connections using outdated or insecure protocols are rejected.

Data at Rest

Data stored by Collabound is protected using encryption at rest:

• Database encryption — Collabound uses a MySQL database with encryption at rest enabled. All data stored by Collabound, including shared work item list metadata, workspace details, and user information, is encrypted on disk.
• AWS infrastructure — Collabound is hosted on Amazon Web Services (AWS), leveraging AWS-managed encryption services for storage volumes and database instances.
• Backup encryption — Database backups are also encrypted, ensuring that data remains protected throughout its lifecycle.

Data Storage and Retrieval

Collabound limits stored Jira work item data to the information needed to display shared work item lists, enforce access controls, and support auditability. This includes list-level fields such as issue key, summary, status, issue type name and icon, project name and icon, and sharing state.

Detailed issue content needed for the work item detail page, such as description, attachments, comments, and other non-list fields, is retrieved from Jira in real time through authorized API calls when an authorized user opens the detail view. Collabound does not need to persist a full copy of every Jira issue detail field in order to provide the shared work item detail experience.

Access Control

Collabound enforces strict access control boundaries to prevent unauthorized data access:

• Workspace-level isolation — Each workspace's data is logically isolated. Users can only access data belonging to their own workspace and data explicitly shared with them through active collaborations.
• Role-Based Access Control (RBAC) — Users are assigned roles within their workspace, and each role carries a specific set of permissions. Permissions are scoped to actions such as viewing work items, sharing issues, managing collaborations, configuring templates, and administering the workspace.
• Field-level access control — Shared Content Access Templates provide fine-grained control over which Jira issue fields are visible to partners. Administrators can select exactly which fields (summary, description, status, priority, custom fields, comments, and more) are included in shared content.
• Sharing Permission Templates — Sharing Permission Templates define the rules governing who can initiate shares, with which workspaces, and under what conditions. These templates ensure that sharing is intentional and controlled.

Audit Logging

Collabound maintains a comprehensive audit trail of all security-relevant events to support accountability and compliance:

• Share and revoke actions — Every share and revoke operation is logged, including the user who performed the action, the affected work item, the target workspace, and the timestamp.
• Authentication events — Login attempts, token issuance, and session events are recorded.
• Workspace changes — Modifications to workspace settings, site bindings, collaboration status changes, and template updates are tracked.
• User management — User invitations, role assignments, and account changes are logged.

Audit logs are accessible to workspace administrators through the Collabound Portal, providing full visibility into activity within your workspace.

Atlassian Security

The Collabound Jira integration is built as a Forge app, which provides additional security guarantees from the Atlassian platform:

• Forge runtime — The Collabound Forge app runs on Atlassian's managed infrastructure, not on third-party servers. This means the app executes within Atlassian's secure sandboxed environment.
• Atlassian security guidelines — The app is developed in accordance with Atlassian's security requirements for Forge apps, including secure data handling and privacy best practices.
• Scoped permissions — The Forge app requests only the permissions it needs to function. These include read:jira-work and write:jira-work for reading and updating Jira issues, and other scoped permissions required for the Issue Panel and the in-Jira Collabound pages.
• Marketplace review — The app is distributed through the Atlassian Marketplace and undergoes Atlassian's security review process before publication.

Data Retention

Collabound follows clear data retention practices to minimize data exposure:

• Active shares — Shared work item list metadata is retained in the Collabound system while the share is active. List-level data is kept synchronized with the source Jira issue through update events, while detail-page fields are retrieved from Jira when needed.
• Revoked shares — When a share is revoked, the partner immediately loses access to the shared work item. Collabound retains the necessary revocation metadata and history for auditability.
• Collaboration termination — If a collaboration between two workspaces is disconnected, the collaboration is marked as disconnected and associated partner access is removed or revoked so the partner can no longer access shared work through that collaboration.
• Account and workspace deletion — Upon request, access to account or workspace data can be removed and relevant records can be marked for deletion, subject to legal, security, backup, audit, and operational retention requirements. Data that is no longer required will be removed according to applicable retention and purge processes. Contact support to initiate a data deletion request.

Contact

If you have security concerns, wish to report a vulnerability, need general assistance, or have questions about Collabound's security practices, please contact us at support@collabound.com.

We take all security reports seriously and will respond promptly to any concerns.