Security statement

Group & Project Watchers for Jira · Last updated October 22, 2026.

Publisher: NITROSOFT TECHNOLOGY INC. Security reporting information is available on the support page. Company and data-handling details appear in the privacy policy.

Architecture and boundaries

The app uses TypeScript, Forge UI Kit, Atlassian Forge functions and queues, installation-scoped Forge KVS/Custom Entity Store, and Jira APIs. The app has no external runtime egress, remote backend or external analytics destination. This public website uses separate Microsoft Azure App Service hosting and does not receive application records. Azure and DNS services process visitor request/network metadata to serve and protect the pages. No fixed retention period or absence of provider logging is promised; operational records depend on the hosting configuration and provider services. Support correspondence is also separate from app processing.

Atlassian documents hosted-storage encryption on disk and installation scoping in its storage reference. Nitrosoft® is responsible for application logic, permissions, dependencies and support practices under Forge's shared responsibility model. Platform certifications are not certifications of Nitrosoft® or this app.

Application controls

• Rule settings derive the signed-in principal and project from trusted Forge invocation context and check the caller's Jira project-administration permission on the server. Rule saves validate current group/user availability, active users and project filter membership. They recheck permission before persistence.
• Personal subscriptions are scoped to the signed-in caller and current project. The backend checks project browse access and selected component ownership rather than accepting a browser-supplied account or project identity.
• Background watcher and optional notification operations use app authorization through Jira. Jira's permissions and access restrictions continue to apply. Queue payloads do not grant permissions or establish an active license.
• License checks read the trusted Forge runtime context and deny mutations when missing, inactive or unavailable. Each queued invocation checks its own context; a context is an invocation snapshot, not continuous license-service polling.
• Rule count and rule writes share a conditional transaction. This protects the 100-record limit under concurrent creates. Archive/disable preserves records.
• Work is bounded and paginated. Watcher checks prevent duplicate additions, and continuations respect rate-limit delays. A retained notification claim/marker prevents automatic resend after an ambiguous outcome; delivery is best effort.
• Persistent application records contain identifiers, configuration, the matched rule-plan hash, counters, statuses and retry timestamps. Issue summaries, descriptions, comments, email addresses and display labels are not copied into these records. The privacy policy explains retained and stalled user-ID records.
• Notification requests use fixed text, explicit recipient account IDs and Jira Browse restrictions. They do not broadcast to all watchers, reporter, assignee, voters or groups through the notification request's recipient selectors.

These controls do not establish a guarantee of uninterrupted processing, email receipt, vulnerability absence or completed independent penetration testing.

Permission purposes

The app requests storage access, read access to the Jira work metadata and user/group information required by these features, and Jira write access for adding watchers and requesting optional notifications. App code does not edit issue summaries, descriptions or comments. Administrative UI placement does not itself grant authority: the backend verifies Jira permissions separately. The exact declared scope set is subject to change when app features change; customers review Forge installation and upgrade consent.

Retention, logging and dependencies

The app has no general record-expiry or automated privacy-erasure workflow. Rules and disabled subscriptions are retained. Notification account lists clear only after a terminal status is successfully written; stalled records can retain them indefinitely. Notification markers have no automatic expiry. One-day throttle keys are a separate mechanism. See the privacy policy for details.

Application-authored notification logs contain fixed status labels. Platform diagnostics can contain invocation/request metadata. The app has no declared external log-export destination. This statement does not promise a fixed log-retention period or certify that all platform logs contain no personal data.

Third-party dependencies can be affected by security advisories. Hosting on Forge does not establish that every dependency is free of known vulnerabilities. No clean-audit claim is made here.

Website support controls

The support endpoint runs separately from Forge on the existing Windows Azure App Service plan. It validates the five requested fields, requires an antiforgery cookie and token plus the fixed site origin, rejects oversized requests, and uses a hidden honeypot and bounded per-worker rate limits. A one-use form identifier prevents the same form from creating another ticket after an uncertain response. Limits reset on a worker restart and are not a distributed abuse-prevention guarantee.

Credentials stay server-side. The server checks access to the fixed support project and sends requests only to fixed Atlassian endpoints. It stores customer-supplied details as a labeled issue in the internal Nitrosoft® Jira support queue, never in a browser-accessible file. It has no email-delivery integration; Jira administrators control Atlassian project notifications separately. Application output does not log submitted content, credentials or raw Jira responses. No submission is claimed successful until Jira returns a ticket ID. The server does not follow the customer-provided site URL. Support records and essential antiforgery/rate-limit data are described in the privacy policy.

Report a concern

Use the support form and choose Security. Prepare the affected app version, operation, impact and reproduction steps using synthetic data where possible. Do not include passwords, API tokens, customer issue content or unnecessary personal records. The same form accepts privacy requests. No response-time or resolution SLA is stated. Do not perform destructive testing on another customer's installation.

No SOC 2, ISO 27001, bug-bounty membership, completed penetration-test report, availability guarantee or Runs on Atlassian badge is claimed by this statement.