Security And Data Handling Statement

Security Posture

The app is a Forge-first Jira Cloud app. The current security posture is:

• least-privilege Atlassian scopes
• read-only access to Jira dependency data
• app-owned storage limited to configuration and saved views
• no external data egress unless a future release explicitly adds it
• no Atlassian user passwords or API tokens collected or stored
• tenant-scoped storage through Forge app storage

Security Summary

Dependency Radar is a Forge-first Jira Cloud app with a read-only security posture in its current version. It visualises cross-squad dependency risk using existing Jira issue links, issue fields, statuses, dates, and project metadata.

Jira remains the source of truth; the app does not create, update, or delete Jira issues, links, statuses, dates, or dependency metadata.

The app requests only the Atlassian scopes needed to provide the service: read:jira-work, read:project:jira, read:workflow:jira, and storage:app. These allow the app to read Jira work and project metadata, understand workflow/status configuration, and store app-owned configuration such as saved views, selected projects, sprint calendar settings, matrix period settings, dependency link mappings, and status mappings.

Dependency Radar does not store duplicate Jira issue records or long-lived dependency records. App storage is limited to configuration required for the product to function. The app does not collect Atlassian passwords, Atlassian API tokens, payment card data, private credentials, or personal data unrelated to Jira issue and project context.

The current manifest does not declare external remotes or hostnames. Customer Jira data remains within Atlassian-hosted Forge services and is not sent to an app-owner-hosted backend or third-party processor. Any future feature that adds external analytics, monitoring, AI processing, Forge Remote, new write scopes, or broader data sharing would require a fresh security and privacy review before release.

Access to Jira data is governed by Atlassian authentication, Jira permissions, and the app's approved scopes. Tenant data remains scoped to the installed Jira site through Forge app storage. The current app does not intentionally log credentials, tokens, unnecessary personal data, or sensitive customer content.

Overall, Dependency Radar is intentionally low-data-movement and low-permission: read-only Jira access, limited app-owned configuration storage, no declared external egress, no Jira write access, and Jira retained as the system of record.

Permissions And Scope Justification

No Jira issue write scope is required for the current version.

Data Access

The app reads Jira issue and project information available to the installed app and the current user's Jira permissions. Sprint and Matrix views are generated from existing Jira issue links.

The app does not create or modify Jira issues in the current version.

App Storage

The app stores configuration needed to make the product usable:

• saved views
• selected projects
• sprint calendar settings
• matrix period settings
• dependency link mapping configuration
• done-status mappings

The app does not store duplicate copies of Jira issues or long-lived dependency records. Any later product decision to store Jira-derived records would require updated security and privacy review before release.

External Services And Egress

Current position:

• No external hostnames or remotes are declared in manifest.yml.
• Customer Jira data is not sent outside Atlassian-hosted Forge services.

Any future change to this egress posture will document:

• destination hostname or provider
• data sent
• purpose
• retention period
• security controls
• whether the client can opt out
• whether Atlassian Marketplace security/privacy listing content needs updating

Secrets

The app does not store secrets in source code, URLs, logs, or repository files. If secrets are needed in future, use Forge encrypted environment variables or Forge secret storage as appropriate.

Logging

Application logs do not intentionally include:

• credentials
• Atlassian API tokens
• passwords
• sensitive customer content
• unnecessary personally identifiable information

The current app has no intentional application logging of customer content. Any future operational logging will remain limited to events needed for debugging and support.

Tenant Isolation

Dependency Radar is a Forge Jira Cloud app. Each customer installs the same Marketplace app into their own Jira Cloud site, but the app runs in that site’s Atlassian/Forge installation context. Data and app storage are scoped to that Jira tenant/installation, so another company or Jira site that installs the app cannot read the Jira data or saved configuration of another tenant.

The current protection model is:

• Tenant isolation: Forge app storage is scoped to the installed Jira site. Saved views and settings for one Jira site are not accessible from another Jira site.
• Jira permissions still apply: issue-level data is requested through Jira’s APIs and is governed by Atlassian authentication, approved app scopes, and the current user’s Jira permissions. The app does not bypass Jira permissions to expose issue data to unrelated users.
• No shared external backend: the current app manifest does not declare external remotes or hostnames. Customer Jira data is not sent to an About Thinking-hosted backend, analytics service, AI service, or third-party processor.
• Read-only Jira posture: the app has read scopes plus storage:app; it does not request Jira issue write scopes and does not create, update, or delete Jira issues or links.
• Limited storage: the app stores configuration such as saved views, selected projects, sprint/calendar settings, link mappings, and status mappings. It does not maintain a separate shared dependency database or duplicate long-lived Jira issue records.

Jira customers downloading Dependency Radar from the Marketplace get their own isolated installation against their own Jira tenant. They do not get access to any other Jira tenant data, including saved views, preferences or configuration.

Vulnerability Management

Dependency Radar uses Node.js dependencies in two package scopes:

• the Forge resolver/app package at the repository root
• the Custom UI package in frontend

For each production release, the release owner runs dependency audit checks in both package scopes and treats unresolved high or critical production vulnerabilities as release blockers unless a documented false positive or accepted-risk exception is approved.

Release vulnerability checks include:

• npm audit --omit=dev from the repository root
• npm audit --omit=dev from frontend
• snyk test from the repository root
• snyk test --file=frontend/package-lock.json --package-manager=npm
• review of direct Forge, React, Vite, and Atlassian package updates
• confirmation that the Forge runtime remains on a supported Node.js runtime
• confirmation that generated frontend assets do not intentionally include secrets, tokens, or sensitive customer content

Snyk Scan Results

Snyk CLI 1.1306.1 was run against both package trees.

Backend / Forge resolver package

Top-level packages in use:

• @forge/api 8.0.2
• @forge/kvs 2.0.2
• @forge/resolver 2.0.0
• eslint 9.39.5

Snyk result:

• Project: dependency-radar
• Target file: root package-lock.json
• Dependency count: 54
• Vulnerabilities: 0
• Summary: No known vulnerabilities

Frontend / Custom UI package

Top-level packages in use:

• @forge/bridge 6.1.1
• @vitejs/plugin-react 5.2.0
• lucide-react 0.468.0
• react 19.2.7
• react-dom 19.2.7
• vite 8.0.16
• @testing-library/jest-dom 6.9.1
• @testing-library/react 16.3.2
• @testing-library/user-event 14.6.1
• eslint 9.39.4
• eslint-plugin-react 7.37.5
• globals 15.15.0
• jsdom 29.1.1
• vitest 4.1.9

Snyk result:

• Project: dep-plugin-custom-ui
• Target file: frontend/package-lock.json
• Dependency count: 188
• Vulnerabilities: 0
• Summary: No known vulnerabilities

Overall Snyk summary

• Backend: clean
• Frontend: clean
• Total Snyk vulnerabilities found: 0

Both the backend/Forge resolver package and the frontend/Custom UI package are currently free of known vulnerabilities reported by Snyk. This is the result of the most recent dependency remediation pass, which upgraded direct Forge dependencies and applied safe transitive updates. Vulnerability scans are re-run for each production release.

Security Incident Process

Security incidents include suspected or confirmed unauthorized access, disclosure, modification, loss, or cross-tenant exposure of customer data; a security compromise of the app; or an app issue that materially affects Atlassian systems or customer availability.

Initial incident response process:

1. Triage the report and determine severity, affected tenants, affected data, and whether app availability or Atlassian systems are affected.
2. Preserve relevant evidence and logs without expanding access to sensitive customer data.
3. Contain the issue, including disabling distribution, disabling affected functionality, or deploying a fix if required.
4. Notify affected client contacts according to the commercial agreement and applicable legal or contractual notification obligations.
5. For Marketplace or Marketplace-bound releases, notify Atlassian through the required ecosystem security path when Atlassian reporting criteria are met, including raising the required severity ticket promptly and no later than 24 hours after becoming aware of a qualifying incident.
6. Provide follow-up updates until containment and remediation are complete.
7. Document root cause, customer impact, remedial actions, and preventive actions.

Pre-Production Security Checklist

• Confirm final scopes are minimal.
• Confirm no external egress exists, or document every egress destination.
• Confirm no Jira write scopes are present unless a future feature requires them.
• Confirm root package production dependency audit has no unresolved high or critical vulnerabilities.
• Confirm Custom UI production dependency audit has no unresolved high or critical vulnerabilities.
• Confirm app does not request Atlassian user passwords or API tokens.
• Confirm source, generated frontend assets, and logs do not intentionally contain secrets, tokens, or sensitive customer content.
• Confirm build, lint, and test checks pass for the release candidate.
• Confirm app handles missing permissions gracefully.
• Confirm privacy policy, security statement, support contact, and incident escalation owner are current.
• Confirm any Marketplace Privacy & Security tab answers match the manifest, egress posture, storage posture, and support process.