Hà Mã Tím's home

← Back

Security Policy for Assignee Chain Widget

Effective Date: October 5, 2026

HMT Developer ("we", "us") develops and publishes the Assignee Chain Widget app for Atlassian Jira Cloud on the Atlassian Marketplace. This Security Policy describes how the app handles data and which technical and organizational controls protect it. It is a companion document to our Privacy Policy for Assignee Chain Widget and does not replace it.

1. Reporting a Security Issue

We welcome security reports from customers, administrators, and researchers.

  • Contact: admin@hamatim.com
  • Please include: the affected app version, a description of the issue, steps to reproduce it, and any proof of concept if available.
  • We acknowledge and investigate every report, and we keep the reporter informed while the issue is being remediated.
  • Please act in good faith: do not access, modify, or delete data that does not belong to you, and allow us reasonable time to fix an issue before public disclosure.

The contact address above is the App Security Issues Contact registered for this app with the Atlassian Marketplace, and it is monitored for business use.

2. Application Architecture

Assignee Chain Widget is a Forge app for Jira Cloud. It runs on Atlassian's own hosting platform, so there is no server, container, or database operated by us.

  • App ID: ari:cloud:ecosystem::app/6a86c774-04a9-414e-920f-1921822e2e0c
  • Hosting: Atlassian Forge — backend functions execute inside Atlassian Cloud infrastructure
  • Runtime: Atlassian-managed Node.js runtime (nodejs24.x, arm64, 256 MB), pinned and patched by Atlassian
  • UI modules: a Jira issue panel and a Jira admin settings page, both built with the Atlassian Design System (UI Kit)
  • External network access: none — the app requests no outbound network (egress) permission and calls no server outside Atlassian
  • External storage: none — the app owns no database, file store, log store, or analytics pipeline

3. Data Handled by the App

The app reads only what is required to render the assignee chain widget on a Jira issue:

  • the issue key and the issue creation timestamp;
  • assignee change events (previous and new account identifiers, plus change timestamps) from the Jira issue changelog;
  • display names and avatars for the accounts already visible on your Jira site.

All of this is processed transiently, in memory, inside your own Jira Cloud tenant, and is rendered back into your Jira instance. It is not copied to infrastructure that we operate, and it is not used for any secondary purpose.

The only persisted data is the app's administrator configuration — display order (oldest-first or newest-first), date format (relative or absolute), and timestamp visibility. It is written to Forge Storage (the storage:app scope), which is Atlassian-hosted, encrypted, and scoped to your installation. It contains no issue content and no personal data.

Data flow, end to end:

  • Your Jira Cloud site sends a request to the app's Forge function.
  • The Forge function reads the issue and its changelog through Atlassian's REST APIs, using the app's declared scopes.
  • The result is returned to the issue panel rendered inside your Jira site.
  • The only write the app performs is its own configuration object in Forge Storage.

4. Authentication, Authorization and Access Control

  • No separate accounts. The app has no login, no user database, and no password or token store. Authentication is handled entirely by Atlassian Cloud. The app never sees user credentials.
  • The invoking user's permissions are checked first. In line with Atlassian's Marketplace security requirements, every user-triggered action is validated against the permissions of the user who invoked it, through the Jira permissions API (GET /rest/api/3/mypermissions), before the app performs any operation with its own app-level authority:
  • reading an issue's assignee history requires the BROWSE_PROJECTS permission on that issue;
  • saving the site-wide administrator configuration requires the ADMINISTER permission. A user without the required permission receives an explicit "No access" message instead of data or a silent success.
  • Least privilege. The app requests exactly three Jira scopes: read:jira-work, read:jira-user and storage:app. It holds no Jira write scope, no product administration scope, and no outbound network scope.
  • No vendor-side access. We cannot log in to your Jira site and we do not have access to your Jira data. Support is provided only on the basis of information you choose to share with us.

5. Encryption

  • In transit: all communication between your Jira site, the app, and Atlassian APIs uses HTTPS/TLS enforced by Atlassian Cloud. The app does not accept or issue plaintext HTTP requests.
  • At rest: the app's configuration in Forge Storage resides on Atlassian Cloud infrastructure, with encryption at rest managed by Atlassian. We operate no storage of our own, so there is no additional store to protect.
  • In our development process: no credentials, API tokens, or customer data are committed to the app's source repository. Deployment credentials are held outside the codebase.

6. Data Retention, Deletion and Portability

  • We retain no customer data, because no customer data is transmitted to or stored by us.
  • The app's configuration stays in Forge Storage for as long as the app is installed.
  • Uninstalling the app removes the app's stored data and revokes all API access, following Atlassian's Forge data lifecycle. There is therefore no separate deletion request for a customer to make and no residual backup on our side to purge.
  • Questions about data deletion, export, or retention can still be sent to admin@hamatim.com.

7. Vulnerability Management and Secure Development

Our security practice follows the Atlassian Marketplace app approval and security requirements.

  • Marketplace security review. Releases are submitted to Atlassian's app approval security workflow and are scanned by Atlassian's ECO scanner. Findings raised by Atlassian's review are tracked and fixed before resubmission — for example, a release was previously held for calling app-level APIs without validating the invoking user's permissions, and a subsequent version added explicit permission checks before every such call.
  • Dependency management. The app depends on a deliberately small set of Atlassian-published libraries (@forge/api, @forge/bridge, @forge/react, @forge/resolver) plus React. Dependencies are kept current, and changes to the dependency tree are reviewed when the lockfile is refreshed.
  • Scope review. Adding a Jira scope is treated as a security change: a new scope must be justified by a feature and reviewed before deployment.
  • Secure coding. Data returned by Jira APIs is treated as untrusted. It is rendered as data only; the app does not evaluate dynamic code and does not inject raw issue content as HTML. The app never executes code supplied by users.
  • Change control. All source changes are version-controlled, and each release records what changed, including security fixes.
  • No telemetry or tracking. The app contains no analytics, advertising, or third-party tracking software, and sets no tracking cookies.

8. Certifications and Compliance

  • The app executes entirely on Atlassian Cloud, which maintains the platform-level certifications and attestations for the underlying infrastructure, including SOC 2 Type II, ISO/IEC 27001, ISO/IEC 27017, ISO/IEC 27018, PCI DSS, and FedRAMP authorizations for applicable services. See Atlassian Trust and Security for details and current reports.
  • HMT Developer holds no independent third-party certification for this app. Compliance that depends on infrastructure, physical, or platform controls is inherited from Atlassian.
  • Data protection: because the app does not transfer personal data to us, your Jira data remains under your agreement with Atlassian. Atlassian acts as the processor of record under the Atlassian Data Processing Addendum. If your due-diligence process requires a security questionnaire or additional documentation, contact admin@hamatim.com.

9. Sub-processors

The app uses no third-party sub-processors. All processing is performed by Atlassian on infrastructure it controls. If a future version were to introduce an external service, that change would be reflected in an updated version of this policy and in the app's Privacy Policy before release.

10. Incident Response

If we become aware of a vulnerability or a security incident affecting the app, we will:

  1. contain and assess the impact, and remediate or withdraw the affected version;
  2. notify affected customers and the Atlassian Marketplace through the app listing and release channels, and publish a fixed version together with a changelog entry describing the fix;
  3. record the root cause and the preventive change that was made.

Because the app stores no customer data outside Atlassian, incidents that could expose Jira issue data can only originate from the Atlassian Cloud platform. In such cases we will cooperate with Atlassian and with our customers to the extent our role allows.

11. Changes to This Policy

We review this policy whenever the app's architecture, permissions, or Marketplace requirements change. Updates are published at this URL with a revised effective date, so we recommend reviewing this page periodically.

12. Contact

For security questions, vulnerability reports, or due-diligence requests: