Junban Desk

Junban Desk security policy

Effective date: 7 July 2026

This page describes how the Marketplace (Forge) edition of Junban Desk is secured and how we handle security issues. Junban Desk is a Jira Service Management app built entirely on Atlassian Forge and published on the Atlassian Marketplace by Collaboration Services (“we”, “us”). Because the app runs entirely on Atlassian’s infrastructure, it inherits Atlassian’s platform security controls; this page covers what we do on top of that. See also our privacy policy.

Using the Cloud edition (app.junbandesk.com)? It runs on Cloudflare rather than Forge, so its infrastructure and controls differ from what is described here — though the core guarantee is the same: every Jira call runs as the acting user. See its data-handling disclosure at app.junbandesk.com/privacy. Report Cloud-edition security issues through the same private channels below.

Reporting a security issue

Please do not open public issues for security vulnerabilities. Report them privately via GitHub Security Advisories, or through our support portal.

Include what you found, how to reproduce it, the affected version, and the impact you believe it has. We acknowledge reports within 2 business days and keep you informed through triage and remediation.

How we handle security incidents

Intake and detection — reports through the channel above, plus platform signals from Atlassian and Forge.
Triage — we validate the report and assign a severity (impact combined with exploitability) within 2 business days of confirmation.
Containment and remediation — we develop and prioritise a fix by severity; critical issues are the top priority.
Deployment — as a Forge Cloud app, fixes deploy to all installations at once; customers do not need to upgrade.
Notification — if an incident affects customer data, we notify affected site administrators and cooperate with Atlassian under the Marketplace Partner Agreement and the Forge Data Processing Addendum, within the timelines those require.
Post-incident — we run a root-cause review and track preventive follow-up actions.

Vulnerability management

Reporting and triage — as above: validate, reproduce, scope the affected versions, and rate severity.
Remediation targets — critical: mitigate or fix as soon as possible; high: next patch release; medium and low: next scheduled release.
Dependencies — third-party npm dependencies are tracked in a CycloneDX software bill of materials, one document per shipped component. CI regenerates it on every change and fails the build if the committed inventory no longer matches the lockfiles, so it cannot go stale. Those files are scanned against the OSV advisory database on every change and again weekly, so newly-disclosed vulnerabilities surface without waiting for a code change. Dependency updates are proposed automatically and every change runs forge lint, ESLint, and the automated test suite before release; Forge SDKs are kept current.
Bill of materials on request — customers and their security teams can request the CycloneDX SBOM for a specific released version through support. It is also kept in the sbom/ directory of the source repository.
Disclosure — coordinated disclosure; we credit reporters on request once a fix has shipped.

Key security controls

Access control

Every Jira API call runs as the logged-in user (asUser); Jira’s own permission model governs every read and write, so the app can never exceed the acting user’s permissions.
Least privilege — the app requests only read:jira-work, write:jira-work, read:jira-user, and read:servicedesk-request, plus storage:app for its own configuration.
Changing project settings requires project-admin permission (ADMINISTER_PROJECTS) and an active license, enforced server-side.
Forge tenant isolation keeps each customer’s app data segregated.

Data protection

No external egress — the app declares none in its Forge manifest, and Atlassian enforces this at the platform level, so the app is technically incapable of sending data to non-Atlassian hosts.
No external servers, database, analytics, or tracking.
Only per-project configuration is stored, in the app’s isolated Forge KVS store (scoped to the app and your site). Jira issue, comment, and user data is processed in memory to serve a request and is not retained.
Encryption in transit and at rest, and data residency, are inherited from your Jira site.
All app data is deleted automatically when the app is uninstalled.

Monitoring and logging

The app relies on Atlassian and Forge platform logging and runtime observability to investigate issues; it runs no independent telemetry or external log shipping.
Atlassian monitors the underlying infrastructure — see the Atlassian Trust Center.

Secure development

Changes go through review and an automated test and lint suite before release.
Least-privilege scopes, no secrets in source, and configuration-only storage.

Platform security

Junban Desk runs on Atlassian Forge and inherits Atlassian’s certifications, encryption, and sub-processor governance. See the Atlassian Trust Center and Sub-Processors list.

Contact

Security questions or reports: support portal or [email protected].