Security Policy

Security Policy

Effective Date: December 1, 2025

Last Updated: December 1, 2025

1. Introduction

At Curious Lab Group (a trading name of Gani Software Pty Ltd), security is fundamental to how we build and operate Carbon. This Security Policy describes the security measures, practices, and commitments we maintain to protect your data and ensure the integrity of our Jira application.

Carbon is built on Atlassian’s Forge platform, leveraging enterprise-grade infrastructure and security controls provided by Atlassian, combined with our own security best practices.

2. Platform Security

2.1 Atlassian Forge Platform

Carbon is built as a Forge app, which means it runs entirely within Atlassian’s secure cloud infrastructure:

• Isolated Execution Environment: The app runs in a sandboxed, isolated environment that prevents unauthorized access to other systems
• Managed Infrastructure: All infrastructure, including servers, networking, and runtime environments, is managed by Atlassian
• Automatic Security Updates: The Forge platform receives automatic security patches and updates from Atlassian
• Built-in Rate Limiting: Forge provides automatic rate limiting and protection against abuse

For more information about Forge platform security, see Atlassian’s Forge Security Documentation.

2.2 Cloud Infrastructure

• Hosting: Carbon’s backend infrastructure is hosted exclusively on Atlassian’s cloud platform
• Geographic Data Residency: Data automatically resides in the same geographic region as your Jira instance
• Compliance: Atlassian’s infrastructure maintains SOC 2 Type II, ISO 27001, and other major compliance certifications
• Network Security: All communications are protected by Atlassian’s network security controls

3. Data Security

3.1 Data Storage

Forge Persistent Storage:

• Carbon stores app-specific data using Atlassian’s Forge persistent hosted storage
• Data is encrypted at rest using industry-standard encryption
• Storage access is controlled through Forge’s secure storage API
• No direct storage access is possible from outside the Forge runtime environment

What We Store:

• Template configurations (names, descriptions, scope settings)
• Template structure data (issue types, field mappings, workflow information)
• Job processing status and progress tracking
• Cached metadata for performance optimization

What We Don’t Store:

• Actual issue attachments (only metadata and references)
• Complete copies of your Jira issues
• User passwords or authentication credentials
• Individual user analytics or behavioral tracking data

3.2 Data in Transit

• HTTPS/TLS: All data transmitted between users and Carbon is encrypted using TLS 1.2 or higher
• API Security: All communications with Jira APIs use Atlassian’s secure authentication mechanisms
• No External Data Transfer: Carbon does not transmit your Jira data to external services (except as described in Section 3.4)

3.3 Data Access Controls

• Principle of Least Privilege: Carbon requests only the minimum Jira permissions necessary to function
• User-Context Access: Data access is always performed in the context of the authenticated user
• Permission Validation: All operations validate user permissions before execution
• No Backdoor Access: We have no administrative backdoor access to your Jira data

3.4 Third-Party Services

Carbon integrates with minimal third-party services, all explicitly declared in our app manifest:

Sentry.io (Error Monitoring):

• Purpose: Error tracking and crash reporting only
• Data Transmitted: Anonymized error logs, stack traces, and performance metrics
• No EUD: No end-user data (EUD) from your Jira instance is sent to Sentry
• Compliance: Sentry is an Atlassian-approved analytics service for Forge apps
• Scope: Used exclusively for maintaining app stability and debugging

All external service integrations are disclosed in our app manifest and comply with Atlassian Marketplace requirements.

4. Authentication and Authorization

4.1 Authentication

No Separate Login Required:

• Carbon uses Atlassian’s authentication system exclusively
• Users are authenticated automatically through their Jira session
• No additional usernames, passwords, or API keys are required
• We never handle or store user authentication credentials

4.2 Authorization and Permissions

Granular Permission Model:

Carbon requests the following Jira permissions:

*Impersonation allows Carbon to create issues on behalf of the authenticated user, ensuring proper audit trails and ownership.

Custom Global Permission:

• Carbon defines a custom permission: “Manage All Templates”
• By default, only Jira administrators have this permission
• This permission allows designated users to manage templates created by other users
• Organizations can grant this permission to specific user groups as needed

4.3 User Access Controls

• Template Ownership: Templates are owned by the user who created them
• Scope-Based Access: Templates can be restricted to specific projects
• Permission Checks: All operations validate user permissions before execution
• Audit Trail: All template applications record the user who performed the action

5. Application Security

5.1 Secure Development Practices

Code Quality:

• TypeScript for type safety and reduced runtime errors
• Comprehensive input validation on all user inputs
• Use of parameters to prevent injection
• Structured error handling to prevent information disclosure

Dependency Management:

• Regular dependency updates and security audits
• Automated vulnerability scanning
• Use of well-maintained, reputable open-source libraries only

5.2 Client-Side Security

Frontend Application:

• Carbon’s user interface is a JavaScript application that runs in your browser
• The client-side portion of the app has an in-built mechanism to notify you to refresh your browser whenever a bug fix or security patch is available
• All client-server communications are conducted over HTTPS

5.3 Input Validation and Sanitization

• Validation Layer: All API requests pass through a validation layer
• Schema Validation: Request data is validated before processing
• Sanitization: User inputs are sanitized before processing
• Error Messages: Error messages do not expose sensitive system information

5.4 API Security

• Rate Limiting: Forge provides built-in rate limiting to prevent abuse
• Request Validation: All API requests are validated before processing
• CORS Protection: Cross-origin requests are controlled by Forge platform security
• No Public API: Carbon does not expose any public-facing APIs outside the Forge runtime

6. Incident Response

6.1 Security Incident Management

In the event of a security incident:

1. Detection: Automated monitoring and manual reviews detect potential incidents
2. Assessment: Incidents are immediately assessed for severity and impact
3. Containment: Affected systems are isolated to prevent further impact
4. Notification: Affected customers are notified in accordance with legal requirements
5. Remediation: Root cause is identified and addressed
6. Post-Mortem: Incident is documented and preventive measures are implemented

6.2 Notification

When We Notify:

• Unauthorized access to customer data
• Data breaches or security compromises
• Incidents that may impact service availability or data integrity

How We Notify:

• In-app notifications within Carbon (if system is operational)
• Updates posted to our website
• For critical incidents, we will work with Atlassian Support to coordinate communication and rectification

Timeline:

• Notification within 72 hours of discovering a qualifying incident
• Updates provided as investigation progresses

7. Contact and Questions

7.1 Security Contact

For security-related inquiries, vulnerability reports, or incident notifications:

Email: security@curiouslab.io

Subject: Security - Carbon

7.2 General Security Questions

For general questions about our security practices:

Email: support@curiouslab.io

Support Portal: https://trj.atlassian.net/servicedesk/customer/portal/35

This Security Policy was last updated on December 1, 2025.