Sprint Scope Guard Security Boundary

1. Application data flow

Sprint Scope Guard is a Jira Cloud Forge app. It uses the Jira and Forge storage permissions declared in its manifest to provide the current-sprint scope audit and authorized scope actions.

• Forge storage: Forge KVS stores settings and minimal governance data. Removed-item audit entries contain only the Jira issue key, action reason, and action date; approval and swap bookkeeping retains issue keys and timestamps without descriptive issue fields. Jira summary, priority, status, and story points are fetched from Jira as the current user reads the record; inaccessible or deleted issues are omitted. Jira remains the source of truth. Older records written by previous releases may remain in Forge storage, but their legacy descriptive fields are normalized away before use and are never returned. The settings migration in the current major-4 release never returns or uses a legacy webhook URL, and attempts to delete the old secret after an authorized administrator loads or saves project settings; failed best-effort cleanup is retried on a later administrator access. See Atlassian's Forge storage reference.
• Exports: CSV, JSON, and Markdown exports are created in the user's browser.
• Retention and residency: Forge-hosted data is retained for up to 28 days after uninstallation. Recovery requires a request within 21 days and does not occur automatically on reinstall. Forge documents hosted-storage residency behavior in its data-residency documentation.

Forge permissions (scopes)

The published Marketplace release 4.1.0 declares these 10 Forge scopes.

• read:jira-work — read issues and sprint scope
• read:sprint:jira-software — read sprints
• read:board-scope:jira-software — read board scope
• write:board-scope:jira-software — apply agreed scope swaps back to the board
• read:project:jira — read the project
• read:issue-details:jira — read issue details
• read:jql:jira — evaluate JQL for the JQL functions
• read:app-data:jira and write:app-data:jira — app-scoped Jira data such as settings
• storage:app — Forge storage for settings and minimal governance data

The V2 development candidate additionally declares read:issue:jira-software. That 11th scope is not included in the published Marketplace release 4.1.0.

The manifest declares no external fetch (egress) permissions, so the app cannot send data to a third-party host.

2. Scope-action and external-destination controls

Sprint Scope Guard applies these controls:

• Scope actions: Sensitive actions are server-side and verify project access and issue/project binding before a scope change.
• External destinations: The current major-4 release has no external backend destination or usage analytics. Minimal failure diagnostics remain in Atlassian Forge logs. Browser exports remain local to the user.
• Operations: Forge operational logs, metrics, and alerts are Atlassian-managed platform services and may include platform site, version, and invocation metadata, governed by customer log-sharing settings. They do not make the app anonymous or a zero-data service.

3. Marketplace availability

Sprint Scope Guard is available with a Runs on Atlassian badge. Availability and current pricing are published through Atlassian Marketplace. The badge does not certify SOC 2 or establish a GDPR compliance attestation.

4. Operational logging and security reporting

Application diagnostics contain only an allowlisted operation and code, a release label, a random per-request UUID, and duration. They do not contain Jira content, user data, site data, webhook data, or hashes. Forge automatically adds installation-site, version, environment, invocation, and other platform metadata, so logs are not anonymous. Access depends on customer log-sharing settings and the applicable Atlassian cloud offering; Forge makes app logs available for 30 days. No external telemetry vendor, session replay, or Forge frontend-log EAP is configured. See Forge app logs and logging guidelines.

Report suspected vulnerabilities with the affected product, error code, approximate time, reproduction steps, and non-sensitive evidence. Redact unrelated Jira content; do not send passwords, API tokens, or webhook URLs.

Response targets: Critical vulnerabilities target remediation within 48 elapsed hours after validation; High within 7 business days; Medium within 30 calendar days; Low in a maintenance release. For confirmed incidents affecting security boundaries, we aim to notify affected administrators and Atlassian Security within 24 elapsed hours after confirmation. These are targets, not guarantees or proof of automatic incident detection. Business days follow the published support schedule; release timing depends on validation and Atlassian review.

5. Responsible Disclosure & Security Contact

We welcome responsible security reports from researchers, partners, and customers. If you believe you have discovered a vulnerability, please contact us immediately: