Portal Sub-tasks — Security Information
This document describes the security posture of Portal Sub-tasks, the Atlassian Marketplace app. It is intended for security reviewers at customer organisations evaluating Portal Sub-tasks for installation.
Platform
Portal Sub-tasks is built entirely on Atlassian Forge, Atlassian's hosted application platform. Portal Sub-tasks operates no third-party servers and runs no code outside Atlassian's network. No End-User Data is transmitted outside Atlassian's infrastructure.
What this means in practice
- Every function call executes in Atlassian's sandboxed Node 24 runtime
- Every storage write goes to Forge Key Value Store (encrypted at rest, AES-256, Atlassian-managed)
- Every outbound network call is whitelisted in the Forge manifest and proxied through Atlassian
- The app cannot run code on your servers or your users' machines
Permissions
| Scope | Reason |
|---|---|
read:jira-work |
Read the sub-tasks of a request and list service projects |
read:jira-user |
Confirm the settings page is used by a Jira administrator |
read:servicedesk-request |
Confirm a portal customer can open the request they are viewing |
write:servicedesk-request |
Add the optional public status comment to a request |
storage:app |
Store per-project settings |
Portal Sub-tasks requests no external network access, no Jira write scope for work items, and no administration or user-management scopes.
Authentication
All access is authenticated by Atlassian Forge; the app never sees or stores a credential.
- Customer access is checked first. Before any sub-task is shown, the app confirms - as the viewing customer - that they can open the request. If not, the panel shows nothing.
- Administrators only for settings. Every settings action first confirms the user holds the Administer Jira permission.
- No customer-supplied credentials. There are no API tokens or passwords to enter, rotate or revoke.
Secret handling
Portal Sub-tasks holds no secrets: no API keys, no tokens and no credentials of any kind.
Account actions and data changes
The only change Portal Sub-tasks can make is an optional public comment on a service request when one of its sub-tasks changes status. It is off by default and switched on per project by a Jira administrator. The app never edits, transitions, creates or deletes work items and never manages users, groups or configuration.
App-specific safeguards
- Customers only ever receive the allowed fields (summary, status and the optional due date, percent done and key). Everything else is excluded, regardless of settings.
- Denied, switched-off and failed requests all look the same to the customer: an empty panel.
- Sub-tasks with the internal label are never shown and never trigger a comment.
- Settings are validated before they are saved.
Vulnerability reporting
Security vulnerabilities can be reported to security@taskhooker.com. We commit to acknowledging reports within 5 business days and disclosing patches via the Marketplace "What's new" section.
Portal Sub-tasks is a solo-developer product. We do not currently operate a paid bug bounty programme.
Compliance
Portal Sub-tasks inherits the security and compliance posture of the underlying Atlassian Forge platform. Atlassian Forge is certified under:
- SOC 2 Type II
- ISO 27001 / 27017 / 27018
- PCI-DSS (for the platform itself; Portal Sub-tasks does not handle payment data)
- GDPR and CCPA compliance commitments
Portal Sub-tasks itself does not have independent certifications. The app code is reviewed by Atlassian as part of the Marketplace listing approval process.
Audit & change history
For your records, every code change to Portal Sub-tasks is reflected in the What's new section of the Marketplace listing for each version. The Marketplace partner portal also exposes a full version history for compliance audits.