Security Policy — Invisible Work Risk Index (IWRI)

Last updated: 23 April 2026
Effective date: 23 April 2026

This Security Policy describes the security practices and architectural properties of the Invisible Work Risk Index Atlassian Forge app ("IWRI", "the app", "we", "our"). It is intended for Jira Cloud administrators, procurement reviewers, and security teams evaluating IWRI for installation or continued use.

1. Who we are

IWRI is developed and maintained by Ayman Idris (sole developer, ABN 59 540 661 752), operating in Australia.

• Developer contact: idrisayman88@gmail.com
• Security contact: idrisayman88@gmail.com (subject line "IWRI security disclosure")
• App name: Invisible Work Risk Index
• Platform: Atlassian Forge (Jira Cloud)

2. Security by architecture

IWRI's security posture is primarily a function of architectural choices, not of operational controls operated by the developer. The app is a pure Atlassian Forge app with the following properties:

• Runs entirely inside the Atlassian Forge sandbox. All backend and UI code executes on Atlassian-managed AWS infrastructure within the customer's Atlassian Cloud tenancy.
• Zero external network egress. The app's Forge manifest declares no external fetch, image, script, or style domains. The codebase contains no fetch(), XMLHttpRequest, WebSocket, or third-party HTTP client calls at runtime. No customer data ever leaves Atlassian's infrastructure.
• No developer-operated infrastructure. The developer does not run any server, database, analytics pipeline, log aggregator, or backend service that receives customer data.
• Read-only Jira access. The app requests no write scopes for Jira. It cannot create, modify, or delete any Jira entity (issue, sprint, project, user, or comment).
• Inherited platform controls. The app inherits Atlassian Cloud's platform security controls — authentication, encryption in transit and at rest, tenant isolation, availability, DDoS protection, platform patching, and compliance certifications (SOC 2 Type II, ISO 27001, GDPR processor commitments, and others listed in the Atlassian Trust Center).

The direct consequence: the classes of vulnerability an external SaaS service usually has to defend against (data exfiltration via a compromised server, credential leaks in transit, supply-chain-injected telemetry, etc.) are not architecturally reachable by IWRI because no such components exist.

3. Authentication and authorisation

• End-user authentication is performed by Atlassian. IWRI never sees, handles, or stores user credentials, OAuth tokens, or session tokens. These are managed entirely by the Forge runtime.
• Jira API calls are made through @forge/api using asUser() by default (so calls are scoped to the caller's Jira permissions) and asApp() only where platform documentation specifies it is required (for example, computation jobs that must see all eligible projects regardless of the triggering user).
• In-app authorisation is enforced at each resolver boundary. Settings resolvers require the caller to hold Jira ADMINISTER permission or to be present in the app's administrator list; visibility of risk scores to non-admins is governed by the access rules configured by an administrator (global, group-scoped, or admin-granted).
• No shared secrets. The app has no API keys, database passwords, or third-party service credentials to manage, rotate, or protect.

4. Data handling

4.1 Data in transit

All communication between the app's frontend and its backend resolvers is handled by the Forge platform over HTTPS. All Jira API calls from the backend use @forge/api, which routes to Atlassian's own APIs over the platform's internal trust boundary. The app makes no outbound network calls of its own.

4.2 Data at rest

All app-managed data is stored in Atlassian Forge Key-Value Storage (@forge/kvs), which inherits Atlassian's encryption-at-rest, tenant isolation, and backup guarantees. Stored data is scoped to the customer's installation and is not accessible to the developer.

4.3 What is persisted

The app persists only the minimum data required for its function:

• Aggregated, cohort-level risk scores (a minimum population threshold is enforced; sub-threshold cohorts are not persisted)
• Administrator-configured settings (computation schedule, excluded projects, team groups, access rules, administrator list)
• Audit metadata for administrator actions (for example, the display name of the administrator who last changed a board override)
• Administrator-authored annotations (free-text notes) on projects
• Per-user UI state (bookmarks, onboarding progress), keyed by account ID

The app does not persist issue descriptions, comments, attachments, worklogs, email addresses, avatars, or individual-level metric values. Personal data stored is limited to display names and account IDs used for access control and audit purposes.

4.4 Data retention and deletion

Administrators may delete configured data (run history, annotations, access rules) from within the app. When the app is uninstalled, app-managed Forge storage is subject to Atlassian's Forge data-deletion policy. See our Privacy Policy for full details.

5. Application security controls

5.1 Input validation

Every resolver validates its input at the entry point using Zod schemas. Payloads are parsed with safeParse(); unknown shapes, unknown enum values, or out-of-range values are rejected with a structured error rather than coerced or partially accepted.

5.2 Injection prevention

• Jira REST calls: all calls use @forge/api's route tagged template literal. User-supplied values flow through parameter binding, never through string concatenation. This eliminates URL-injection paths.
• JQL: no user-controlled strings are interpolated into JQL queries. The only dynamic values placed into JQL are numeric sprint IDs typed as number and sourced from Jira's own Agile API responses.
• Project keys: administrator-supplied project keys (for example, the excluded-projects list) are validated against the authoritative set returned by Jira's project-search API before being persisted.
• No user-supplied URLs: the app accepts no free-text URL fields, redirect targets, or webhook endpoints.

5.3 UI sandbox

The Custom UI pages run inside the Forge iframe sandbox. The app does not use localStorage or sessionStorage, does not perform direct fetch to external domains, and does not use window.open (navigation is performed via router.open from @forge/bridge).

5.4 Content Security Policy

The only CSP relaxation declared in the manifest is permissions.content.styles: ['unsafe-inline'], required by the @atlaskit CSS-in-JS styling system used throughout the UI. No external script, style, or image hosts are declared.

5.5 PII-safe logging

Structured JSON logging is used throughout. Account IDs that appear in logs (for bookmarks, onboarding, audit trails) are hashed using a 16-character SHA-256 prefix before being logged; raw account IDs are not written to logs.

6. Secure development lifecycle

• TypeScript strict mode across the entire codebase, with any disallowed by project convention.
• Pre-commit hooks (Husky) run lint, typecheck, the backend unit test suite, the Custom UI unit test suites (admin page and global page), and a production build before a commit is accepted.
• Continuous integration: every push runs tests, lint, and a scope-change gate that fails the build if permissions.scopes changes without an explicit justification in the commit.
• Pre-deploy: forge lint runs before every deploy, catching manifest-level issues before upload.
• Review: all material changes are manually reviewed before deployment to production; destructive actions require explicit authorisation.
• No secrets in source: the app has no credentials, API keys, or private configuration values. There is nothing to leak.

7. Dependencies and supply chain

• Minimal surface: backend runtime dependencies are limited to the official @forge/* packages (API, resolver, events, KVS) and zod for input validation. Frontend dependencies are limited to @atlaskit/* components, @forge/bridge, and React 18.
• No telemetry or analytics SDKs. There is no Sentry, Segment, Mixpanel, Amplitude, Google Analytics, PostHog, Datadog, New Relic, Honeycomb, or LaunchDarkly integration. Verified by full codebase search.
• Vulnerability monitoring: dependencies are reviewed for known vulnerabilities using npm audit and GitHub's dependency advisory feed. Critical and high-severity advisories are patched on a priority basis; medium-severity advisories are resolved in the next scheduled release.
• Reproducible builds: package-lock.json is committed; builds are deterministic given a pinned lockfile.

8. Logging and monitoring

• Runtime logs flow to Atlassian's Developer Console via the Forge runtime. The developer does not operate any external log aggregator.
• Logs are structured JSON, with account IDs hashed (see §5.5). Errors are logged with category labels (for example, error.category: 'population_minimum') rather than free-text stack traces that might contain sensitive data.
• Platform-level monitoring and alerting is provided by the Forge platform.

9. Vulnerability management and patching

• Platform vulnerabilities (Forge runtime, Atlassian Cloud infrastructure) are handled by Atlassian and are applied automatically to all installations; no developer action is required.
• App-level vulnerabilities: on becoming aware of a security vulnerability in the app itself or in one of its dependencies, the developer will triage within 2 business days, prioritise remediation by severity, and deploy a fix via Forge's minor-version automatic deployment path for the majority of issues. Severity targets for fix delivery:
  • Critical: within 7 calendar days of confirmation.
  • High: within 30 calendar days of confirmation.
  • Medium: in the next scheduled release, typically within 60 calendar days.
  • Low: reviewed each release cycle.
• Customers are notified of fixes affecting security or data handling via the Marketplace listing's release-notes section.

10. Incident response

If the developer becomes aware of a security incident affecting the app:

1. Acknowledge receipt of any report within 2 business days.
2. Investigate and determine the scope and root cause; engage Atlassian Partner Support for any platform-level involvement.
3. Contain and remediate — deploy a fix via Forge's fix-forward deployment path.
4. Notify affected customers directly and Atlassian per the Marketplace Partner Agreement, if customer data is materially affected. Notifications include what was affected, what has been done, and what (if anything) customers should do.
5. Post-incident review — document the incident, root cause, and preventive changes. Publish a summary in the Marketplace listing if the incident was customer-visible.

11. Backups, availability, and business continuity

• App-managed storage (Forge KVS) is backed up by Atlassian as part of the Forge platform. The developer does not operate any separate backup system.
• Availability inherits from Atlassian Cloud's platform availability posture (see the Atlassian Trust Center).
• Because the app has no developer-operated components, there is no single point of failure beyond the Atlassian platform itself.
• Because the app has no write scopes for Jira data, a complete loss of app state (however improbable) cannot damage customer Jira data. The worst case is the need to recompute risk scores from live Jira data, which the app performs automatically.

12. Data sharing and third parties

No customer data is shared with, sold to, or disclosed to any third party. The app's only subprocessor is Atlassian Pty Ltd, which hosts the Forge platform on which the app runs. The app does not use customer data to train, fine-tune, or evaluate any artificial-intelligence or machine-learning model; the risk-scoring algorithm is deterministic statistical logic implemented in TypeScript.

13. Responsible disclosure

If you believe you have discovered a security vulnerability in IWRI, we encourage you to report it confidentially:

• Email: idrisayman88@gmail.com with the subject line "IWRI security disclosure".
• Please include: a clear description of the issue, reproduction steps, affected version or installation site if known, and your assessment of impact.
• Please do not publicly disclose the issue before the developer has had a reasonable opportunity to investigate and remediate (typically 90 days, or sooner if a fix is deployed earlier).
• Acknowledgement within 2 business days of a valid report.
• Coordinated disclosure with Atlassian where the issue touches platform behaviour.
• Credit: reporters who wish to be credited will be acknowledged in the release notes for the fix. No monetary bug bounty is offered at this time.

For vulnerabilities in the Atlassian Forge platform itself, please report directly to Atlassian's security team.

14. Compliance posture

• Marketplace requirements: the app complies with the Atlassian Marketplace Partner Agreement, Cloud App Security Requirements, and passes Atlassian's Ecoscanner checks required for Marketplace listing.
• Platform certifications: because the app runs entirely within Atlassian Cloud, the platform's compliance certifications (SOC 2 Type II, ISO 27001, ISO 27018, GDPR processor commitments, and others) apply to the infrastructure, storage, and runtime environment on which IWRI executes. Please refer to the Atlassian compliance resources for current certification details.
• App-level certification: as a sole-developer app, IWRI is not separately certified under SOC 2, ISO 27001, or similar frameworks. The app's security posture follows from its architectural choice to run entirely within Atlassian's certified platform with no developer-operated external components.
• Regional data residency follows Atlassian's Forge data-residency behaviour for the customer's tenant.

15. Changes to this policy

We may update this Security Policy from time to time. Material changes — for example, the introduction of a new subprocessor, the addition of any external egress, or a change to the incident-response process — will be reflected by an updated "Last updated" date at the top of this document and, where material to customers, communicated via the app's Atlassian Marketplace listing.

16. Contact

Security questions, concerns, or vulnerability reports:

Ayman Idris (ABN 59 540 661 752)
Email: idrisayman88@gmail.com