Advanced Structured Gantt

Reviewed 13 October 2026

Security practices

This page describes the security practices of Advanced Structured Gantt, a Jira Cloud app built on Atlassian Forge. It is separate from the privacy policy, which explains the data processed, retention and deletion.

Hosting and authentication

The backend runs as Forge Functions on Atlassian-managed infrastructure. The interface uses Forge Custom UI. The app does not operate a remote backend, expose web triggers or request users' Jira passwords, API tokens or third-party credentials. Jira work item data is read through Forge and displayed in the user's browser.

Authorization and permissions

All Jira API calls in the app's resolvers use asUser(). Jira reads and writes remain subject to the signed-in user's permissions; browser context is not used to grant backend access.

The classic write scope covers more operations than the app implements. The app provides no deletion, comment or worklog action; this is a description of its implemented behavior, not a claim that the scope cannot authorize those operations.

Data handling, transport and encryption

The app does not persist fetched Jira work items or profile data in Forge storage or a developer-operated database. It has no external analytics or external processing service, and its manifest declares no external egress domains. Network security for Atlassian-managed Forge traffic, including TLS, is described in Atlassian's shared responsibility model.

Saved view names, JQL queries, field mappings and display preferences stay in browser local storage, using a namespace based on Jira cloud ID and account ID. Those names and queries may contain personal information. Namespace separation is a preference safeguard, not an authorization or encryption boundary. The app does not add encryption to browser local storage. Device and browser access protections are managed by the user or their organization. If context or persistent storage is unavailable, preferences use temporary memory.

Settings > Browser records provides a confirmation before clearing saved view names, JQL queries and preferences for the current Jira site and account. Other account/site namespaces, unrelated browser entries and legacy records are left unchanged. If browser storage cannot be cleared, the app reports the failure. Legacy records can be removed through the browser's site-data controls. Uninstalling alone does not remove browser preferences.

User-requested PDF and PNG reports contain selected Jira data and are downloaded to the user's device. Reports do not receive app-managed encryption. Users control retention and subsequent sharing; the browser-records control does not delete downloaded reports.

Input validation and output handling

Resolver inputs are checked for valid issue keys, real calendar dates, ordered date ranges, distinct allowed field identifiers, bounded query and page-token lengths, and allowed requested-field identifiers. Before a date change, the backend checks the work item's date-field metadata and reads the current dates for the confirmation preview. Jira edit metadata can omit fields that are not on an edit screen. For those fields, the backend checks their date type using server-fetched issue schema and checks the current user's issue-specific edit permission. The Jira update API remains the final authority for field, project and workflow restrictions. Saving requires explicit confirmation and another field and date check. A change is refused if the current dates differ from the preview. Undo also checks that the dates still match the last saved change and can restore previously empty dates.

These checks reduce accidental overwrites but are not an atomic comparison and update: another edit can occur between the final Jira read and write. Jira enforces edit permissions. Displayed issue and user text is rendered as text or escaped in timeline templates. Malformed saved filter settings are filtered before use. Cancelled or failed date changes restore the last confirmed timeline data.

Dependency checks and vulnerability management

The deployment script runs automated production dependency audits for the backend and frontend and stops on reported production vulnerabilities. Repository checks run on pushes, pull requests and a weekly schedule. Production audits block those checks; full audits, including development tools, are reported separately. Dependabot checks application and workflow dependencies weekly and proposes updates. Updates require review and successful relevant checks before integration.

The production dependency audits on 13 October 2026 reported zero vulnerabilities for both the backend and frontend. After updating the official Forge CLI to 14.2.0, the full backend audit on that date still reported 40 findings in its development-tool dependency chain: 3 low, 9 moderate, 25 high and 3 critical. A standard audit fix did not resolve these findings. They are tracked separately and are not represented as resolved. An audit is a point-in-time result, not a guarantee that the app or its development tools are free of vulnerabilities.

New findings are assessed for affected components, deployed exposure and severity. Remediation and notifications follow the applicable Atlassian Marketplace Security Bug Fix Policy. Relevant changes are checked with regression tests, a production build and Forge lint before release.

Logging, assessments and certifications

The app does not intentionally log Jira work item content, personal information, passwords or tokens. Atlassian manages platform operational logging. The app does not claim an independent security certification, completed penetration test or active Marketplace bug bounty membership. Dependency scans, code review and targeted local browser checks are not a substitute for an independent penetration test.

Security reports and incident handling

Contact the app owner, Veysel Baysal, at vyslbaysal@gmail.com to report a suspected issue. Include the app version, affected feature and a minimal reproduction using sample data. Do not send passwords, tokens or unnecessary customer data.

Reports are assessed to establish impact and affected versions. Confirmed security incidents are escalated to Atlassian through ECOHELP and affected customers are notified as required by Atlassian's security incident guidance. Mitigations and fixes are verified before affected functionality is restored.