Policy

Policy

1. General Provisions

1.1 Purpose

To regulate the development, release, operation and other behaviors of relevant applications (hereinafter referred to as "Atlassian App") developed by our team (hereinafter referred to as "Developer") based on the Atlassian platform (including but not limited to Jira, Confluence, Forge, etc.), protect the legitimate rights and interests of users, the security of the Atlassian platform and the compliance of the Developer itself. In addition, this Policy describes, at a high level, the security and privacy controls the Developer applies to the Atlassian App and any related backend systems, so that customers can understand how the app and their data are protected.​

This Policy is formulated in accordance with the Atlassian Developer Terms, the Atlassian Marketplace security requirements, the Cybersecurity Law of the People's Republic of China, the Data Security Law of the People's Republic of China, the Personal Information Protection Law of the People's Republic of China and relevant international laws and regulations (including, where applicable, the EU GDPR).

1.2 Scope of Application

This Policy applies to the entire process of development, testing, release, update, maintenance, operation and other related work of all Atlassian Apps by the Developer, as well as the supporting systems used to build, deploy and operate the apps (source code repositories, CI/CD, secrets management, hosting, monitoring, support tools)​, and to all personnel and partners involved in related work.

1.3 Basic Principles

The Developer commits to strictly abide by all rules and requirements of the Atlassian platform, adhere to the principles of legality, integrity, security and transparency, adhere to the bottom line of data security and user privacy protection, refuse any illegal development and malicious operation behaviors, and actively cooperate with the review, supervision and compliance inspection of the Atlassian platform.

2. Development Compliance Requirements

2.1 Technical Compliance

The Atlassian Apps developed by the Developer must comply with the technical specifications of the Atlassian platform, including but not limited to API calling standards, integration protocols, and secure development specifications. It is not allowed to bypass platform restrictions, tamper with platform functions or bypass platform review mechanisms.

All Apps must undergo sufficient testing, including unit, integration, security (SAST and dependency scanning) and, for higher-risk changes, threat modeling and penetration testing, to ensure no malicious code, vulnerabilities and compatibility issues, so as to avoid affecting the normal use of the Atlassian platform and users.

2.2 Certification Compliance

The Developer must complete the personal and business identification (KYC/KYB) process in accordance with the requirements of the Atlassian platform, provide true, accurate and complete identity information and enterprise qualifications, and shall not provide false information or use others' / enterprises' identities for development and release operations.

2.3 Permission Compliance

The permissions applied by the App on the Atlassian platform must be strictly matched with its own functions. Only the permissions necessary for realizing core functions can be applied for. It is not allowed to excessively apply for permissions or abuse permissions to obtain user or platform data. Collecting and storing sensitive credentials such as Atlassian API tokens and user account passwords is strictly prohibited, and the authentication method migration has been completed (starting from January 1, 2026, the officially supported authentication methods of Forge or 3LO/OAuth 2.0 are fully used). Any tokens that must be handled in transit are stored only in a managed secrets vault, never in source code, log files or screenshots.​

3. Data Security and Privacy Protection

3.1 Data Collection

The Developer may only collect user data necessary for realizing App functions. Before collection, the Developer must clearly inform users of the scope, purpose, use and retention period of data collection, obtain users' explicit consent, and shall not force or secretly collect user-irrelevant data.

3.2 Data Storage and Protection

The Developer must take security measures such as encryption, access control and vulnerability protection to properly store user data and platform-related data to prevent data leakage, tampering and loss. Specifically:​

  • Data in transit is protected with TLS 1.2 or above using modern cipher suites.​

  • Data at rest, where persisted outside the Atlassian platform, is encrypted with industry-standard algorithms (for example, AES-256) using keys managed via the cloud provider's KMS.​

  • Customer data is logically isolated by tenant and is not exposed across customers.​

  • Where the App relies on Atlassian-managed storage (e.g., Forge storage, Confluence/Jira entities), the encryption, isolation and residency controls inherited from Atlassian apply.​

The Developer strictly complies with the Atlassian data security policy, cooperates with the platform's data access rules, and shall not access or obtain data content restricted by the platform.

3.3 Data Use and Sharing

User data can only be used for the realization of the App's own functions, not for other commercial purposes, and shall not be disclosed, sold or transferred to third parties unless the user's written consent is obtained or otherwise required by laws and regulations. If it is necessary to integrate third-party services, the user must be informed in advance, and it must be ensured that the third-party services comply with the relevant provisions of data security and privacy protection. A list of subprocessors used to operate the App, the categories of data shared with each, and the location of processing is maintained and made available on request.​

3.4 Data Retention and Deletion

The Developer must set a reasonable data retention period in accordance with the principle of "minimum necessity and shortest retention", and delete the relevant data in a timely manner after the retention period expires; when a user requests data access, modification or deletion, the Developer must respond and complete the processing within a reasonable time limit to protect the user's data sovereignty. When the App is uninstalled or a customer requests deletion, App-managed customer data is removed within a defined retention window, in line with Atlassian's data residency and deletion guidance.​

4. Release and Operation Compliance

4.1 App Release

The Developer must submit complete App information (including function description, user guide, privacy policy, and security/data handling information where required by the Atlassian Marketplace) in accordance with the release process of the Atlassian Marketplace, and can be officially released only after passing the platform's security review and compliance review. The released App information must be true and accurate, and shall not exaggerate functions or conceal known problems.

4.2 App Update

The Developer must continuously maintain the App, timely fix security vulnerabilities and optimize functions. If it involves function changes, permission adjustments, data processing method changes, etc., it must be announced in advance on the Atlassian Marketplace and its own channels, and re-pass the platform review (if necessary). Security patches for Critical and High severity vulnerabilities are prioritized and released as out-of-band updates where appropriate.​

4.3 Prohibited Behaviors

It is strictly prohibited to release Apps containing malicious code, viruses and Trojans; it is strictly prohibited to release Apps that infringe on others' intellectual property rights, trade secrets and privacy; it is strictly prohibited to release Apps with false propaganda, inducing users to pay and harassing users; it is strictly prohibited to use Apps to engage in illegal and irregular activities, including but not limited to network attacks, data theft, illegal profit-making, etc.

5. Intellectual Property Rights and Compliance Liabilities

5.1 Intellectual Property Rights

The Developer commits to owning all intellectual property rights required for the development of Atlassian Apps, or having obtained relevant authorization, and shall not infringe on the trademarks, patents, copyrights, trade secrets and other intellectual property rights of Atlassian and third parties. The Developer retains the intellectual property rights of its own Apps, but shall not use the Apps to infringe on the intellectual property rights of the Atlassian platform.

5.2 Compliance Liabilities

The Developer shall independently bear all liabilities arising from violating this Policy, the Atlassian platform rules and relevant laws and regulations, including but not limited to administrative penalties, civil compensation, platform penalties (such as removing Apps from the shelves, terminating cooperation), etc. If the Developer's illegal behaviors cause losses to the Atlassian platform or users, the Developer shall bear compensation liabilities in accordance with the law.

6. Security Controls

This section gives customers a high-level view of the security controls the Developer applies to the Atlassian App and any related backend services.

6.1 Secure Development Lifecycle
  • All code changes go through peer code review on protected branches before merge.

  • Each build is automatically scanned with SAST and software composition analysis (SCA) to detect insecure patterns and vulnerable dependencies.

  • Higher-risk changes are subject to threat modeling and additional security review.

  • Production deployments run from a controlled CI/CD pipeline with required security checks; manual production access is logged and minimized.

  • Controls and tests are aligned with the OWASP Top 10 and OWASP ASVS where applicable.

6.2 Infrastructure and Operational Security
  • Backend services (where present) run on reputable cloud providers in segmented, hardened environments; production is separated from development and test.

  • Hosts and container images are based on hardened baselines and patched on a defined cadence.

  • Application, system and security-relevant events are centrally logged; alerts are configured for anomalous activity, authentication failures and known indicators of compromise.

  • Persistent data stores are backed up on a regular schedule with encryption and periodic restore tests.

  • Production changes follow documented review and approval; emergency changes are logged and reviewed retrospectively.

6.3 Access Control
  • Access to production systems and customer data is granted on a need-to-know, least-privilege basis.

  • Multi-factor authentication is required for source code, cloud consoles, CI/CD and any administrative access to production.

  • Access rights are reviewed at least quarterly and revoked promptly when an employee or contractor changes role or leaves.

  • All personnel with production access sign confidentiality agreements and complete annual security and privacy training.

6.4 Vulnerability Management
  • Findings are sourced from vendor advisories, CVE feeds, dependency scanners, internal testing, customer reports and external researcher submissions.

  • Each finding is triaged with CVSS v3.1, taking into account exploitability and exposure.

  • Target remediation timelines:

Severity

Target time to remediate or mitigate

Severity

Target time to remediate or mitigate

Critical

Within 7 days

High

Within 30 days

Medium

Within 60 days

Low

Within 90 days

  • Independent penetration tests are commissioned at least annually and after major architectural changes; findings are tracked to closure, and a summary report is available under NDA on request.

6.5 Security Incident Management
  • The Developer maintains a documented incident response process aligned with NIST SP 800-61 phases (preparation, detection and analysis, containment, eradication, recovery, post-incident review).

  • Incidents are classified by severity based on confidentiality, integrity and availability impact, and on the volume and sensitivity of affected data.

  • If an incident is confirmed to involve unauthorized access to or disclosure of customer data, affected customers are notified without undue delay, in line with applicable laws (including GDPR Art. 33 where relevant) and Atlassian Marketplace requirements. Notifications include what happened, what data was involved, what has been done, and what customers should do.

  • Where required, the Developer notifies the relevant data protection authorities within the legally mandated timeframes.

  • Each significant incident is followed by a written post-mortem with corrective actions tracked to completion.

6.6 Responsible Disclosure
  • Security researchers and customers can report vulnerabilities to the security contact listed in section 7.3.

  • The Developer commits to acknowledging receipt within 3 business days, providing an initial assessment within 10 business days, keeping the reporter informed about progress, and not pursuing legal action against researchers acting in good faith and in line with this policy.

  • Researchers are asked to avoid actions that could harm availability, integrity or privacy of users, only test against tenants they own or are authorized to test, and give the Developer a reasonable time to remediate before any public disclosure.

6.7 Business Continuity and Disaster Recovery
  • A documented Business Continuity and Disaster Recovery plan defines roles, communication and recovery procedures.

  • Recovery objectives (RTO/RPO) are defined per service tier and shared with customers under NDA on request.

  • Backups are encrypted, stored in a separate availability zone or region, and tested via periodic restore drills.

6.8 Compliance Alignment

The Developer aligns its security program with widely recognized standards and frameworks, including ISO/IEC 27001 controls, SOC 2 Trust Services Criteria (Security, Availability, Confidentiality), OWASP Top 10 and ASVS, GDPR and other applicable privacy regulations, and the Atlassian Marketplace security requirements (including Cloud Fortified / Cloud Security Participation where applicable).

Note: replace "aligns with" with "is certified to" only where the Developer has actually obtained the certification, and list the certificate name, scope and issuing body.

7. Policy Update, Interpretation and Contact

7.1 Policy Update

This Policy will be adjusted in a timely manner according to the update of the Atlassian platform rules, the revision of relevant laws and regulations and the needs of business development. After the update, it will be publicized in a prominent position on the Developer's website, and will take effect automatically after the publicity period. If the Developer continues to operate the Atlassian App, it shall be deemed to accept the updated Policy. The Policy is reviewed at least once per year and whenever there is a material change to the App or its environment.​

7.2 Policy Interpretation

The final interpretation right of this Policy belongs to the Developer. If the Developer has any questions about this Policy, it can consult through the official contact information; if there is any conflict with the Atlassian platform rules, the Atlassian platform rules shall prevail.

7.3 Contact

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

Security contact: 178501696@qq.com