Security

ArtUp Trace for Jira Cloud · Last updated: 2026-09-25

1. Architecture

ArtUp Trace is built entirely on Atlassian Forge and carries Atlassian's "Runs on Atlassian" designation. This means:

• The App's code executes inside Atlassian's infrastructure, not on a server operated by ArtUp Labs. ArtUp Labs runs no external servers for the App.
• The App has no outbound network calls (no egress). It cannot send Jira data anywhere outside Atlassian.
• The App's own data (project settings, requirement and link records, baselines, sync job metadata) is stored only in Forge SQL and Forge storage, in the customer's data residency region as handled by Atlassian.
• The App and this website load no third-party analytics, trackers or advertising scripts.

See the Privacy Policy for the full list of what is stored.

2. Access scopes and permissions

The App follows the principle of least privilege. It requests only the Atlassian scopes it needs, and nothing more:

The App requests no write scopes for Jira issues. It reads Jira data as the current user, so it can only see what that user is already permitted to see in your Jira site, and it never writes to Jira issues.

Beyond the scopes above, the App performs a Jira permission check on every user-facing action before it acts — for example before showing an issue's traceability data or before recording a link confirmation — so a user cannot use the App to see or affect anything their own Jira permissions would not already allow.

3. Application security controls

• Permission checks on every action. Every user-facing operation re-checks the calling user's Jira permissions at the time of the request; nothing is cached in a way that could grant stale access.
• Input validation. All input from the front end, from Jira webhooks, and from imported data (for example CSV or configuration values) is validated before it is stored or used to build a query, to guard against malformed or malicious input.
• No egress, no trackers. Because the App cannot make outbound network calls, there is no path for it to exfiltrate data even if a dependency were compromised.
• Least-privilege storage. Only the fields needed for traceability are stored; see the Privacy Policy for the exact list. Full issue description text is never stored, only a change-detection hash.

4. Dependency and supply-chain security

• Automated scanning. npm audit runs as part of the build, and Dependabot is enabled on the source repository to flag known vulnerabilities in dependencies and open update pull requests automatically.
• Review before release. Dependencies are checked for known vulnerabilities before every release, not only on a schedule.
• Minimal dependency footprint. The App uses as few third-party packages as practical, to reduce supply-chain exposure.

5. Account and workstation security

• Multi-factor authentication (MFA) is enabled on the developer's Atlassian, source control, email, DNS and app-store accounts.
• Full-disk encryption and automatic OS updates are enabled on the development workstation.
• Unique, generated passwords are used and kept in a password manager.
• Secrets and credentials are kept out of source control and rotated periodically and immediately after any suspected exposure.

6. Reporting a vulnerability

If you believe you have found a security vulnerability in ArtUp Trace or on this website, please email security@artuplabs.com with:

• a description of the issue and its potential impact;
• steps to reproduce it, including any request or response details that help us confirm it;
• whether any customer data was, to your knowledge, affected.

Please do not include Jira content beyond what is strictly needed to demonstrate the issue, and do not test against customer sites you do not control. We will acknowledge your report within 24 hours and keep you updated as we investigate and fix it. We currently do not run a paid bug bounty programme.

7. Incident response

ArtUp Labs follows a written incident response plan for every Marketplace app, owned by the security contact below and reviewed at least once a year and after every incident.

7.1 What counts as an incident

• Unauthorised access to customer data held by an app (Forge SQL, Forge storage).
• A vulnerability in an app that exposes customer data or lets a user act beyond their Jira permissions.
• Compromise of a developer account, workstation, source repository or deployment credentials (Atlassian account, Forge token, source control, domain/DNS, email).
• A report from Atlassian (Marketplace Security ticket, bug report) or from a customer about any of the above.

7.2 Detection channels

• security@artuplabs.com and hello@artuplabs.com, checked daily on business days.
• Atlassian Marketplace Security (AMS) tickets on ecosystem.atlassian.net.
• The Forge developer console: app logs, invocation errors and alerts.
• Dependency alerts (npm audit, Dependabot).

7.3 Response steps

7.4 Preventive controls

• Full-disk encryption and automatic OS updates on the development workstation.
• Multi-factor authentication on Atlassian, source control, email, DNS and app-store accounts.
• Unique passwords kept in a password manager; secrets kept out of source control and rotated regularly and after any suspected exposure.
• The App runs on Atlassian (Forge) with no external egress, least-privilege scopes, and a permission check on every user-facing operation.
• Dependencies are checked for known vulnerabilities before every release.

8. Contact

Security contact: security@artuplabs.com. For general questions, see our Support page. For what data is stored and how, see our Privacy Policy.