Hooks — Security Information

This document describes the security posture of Hooks, the Atlassian Marketplace app. It is intended for security reviewers at customer organisations evaluating Hooks for installation.

Platform

Hooks is built entirely on Atlassian Forge, Atlassian's hosted application platform. Hooks 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

Hooks requests the following Atlassian permission scopes:

Scope	Reason
`read:jira-user`	Resolve the current app/user profile (`jira.myself()`) and basic user fields a script reads
`read:jira-work`	Read Jira work items — the fields a script fetches via `jira.search`, `jira.getIssue`, `jira.forEachIssue`, or `jira.request`
`write:jira-work`	Let an administrator's script modify Jira work items — add comments, update fields, transition items, or call a Jira write endpoint via `jira.request`
`storage:app`	Forge Key Value Store — persist administrator-authored scripts, their version history, and run history

Hooks requests only these scopes. It requests no user-impersonation scopes, no group-management scopes, no Jira-configuration or admin scopes, no Confluence scopes, and no report:personal-data scope. It declares no external network egress — permissions. external.fetch is empty, so the app cannot contact any host outside Atlassian's Forge runtime.

The app's effective capability is the intersection of these scopes and what an administrator's script does: Hooks can read and write Jira work-item content, and store its own automation data — nothing more.

Authentication

Hooks uses a single authentication pattern.

Forge-managed authentication (no app-held tokens)

Atlassian's platform mints and attaches every token; Hooks never sees or handles a raw credential. Three patterns are used, all Forge-managed:

Administrator gate — asUser(). Every backend call first verifies that the caller holds the ADMINISTER permission (GET /rest/api/3/mypermissions as the acting user) before doing anything else.
Script-invoked Jira calls — asApp() by default. Calls a script makes (jira.myself, jira.search, jira.getIssue, jira.addComment, jira.updateIssue, jira.transition, jira.forEachIssue, and the generic jira.request) run as the installed app, constrained to the granted scopes.
Console "Run as me" — asUser(). An administrator can flip a console toggle to run a script's Jira calls as themselves, bounding the run by their own Jira permissions. Background executions (event, scheduled, JQL, scripted-field, bulk) have no user in context and always run asApp().

No customer-supplied credentials

Hooks does not collect or store any Atlassian account credentials — no passwords, no user or admin API tokens. All Atlassian access is via Forge-granted app authentication approved at install. There is nothing to paste, rotate, or revoke.

Administrator-only access

Hooks renders as a Jira admin page, which only Jira administrators can open — and every backend resolver independently re-checks the caller's ADMINISTER permission server-side. Authoring, saving, enabling, and running scripts is therefore restricted to administrators — the same trust model as comparable Jira scripting apps.

Secret handling

No customer credentials are stored. Hooks holds no user/admin API tokens, passwords, OAuth tokens, or client credentials. All Atlassian access uses Forge's asApp() authentication, so there is no app-held credential to leak or rotate.
No kvs.setSecret() usage. The Key Value Store holds only administrator-authored scripts, version snapshots, and run records (see the Privacy appendix) — not secrets.
No third-party secret manager is used (no AWS Secrets Manager, GCP KMS, or Vault), because there are no external integrations and no secrets to manage.

Administrators should treat script content as code: a script could be written to log data into its run record. Run records are stored in your own site's Forge KVS, never transmitted off-platform, and bounded to the last 50 runs.

Account actions

Hooks never deletes, suspends, or modifies Atlassian accounts, groups, licences, or configuration. It holds no account- or group-management scopes.

Within write:jira-work, an administrator's script can change Jira work-item content:

Add a comment — jira.addComment(key, text) → POST /rest/api/3/issue/{key}/comment
Update fields — jira.updateIssue(key, fields) → PUT /rest/api/3/issue/{key}
Transition an item — jira.transition(key, id) → POST /rest/api/3/issue/{key}/transitions
Any Jira write endpoint the write:jira-work scope permits, via jira.request(method, path, body)

Every one of these:

Is performed only by an administrator's own script — Hooks ships with no built-in automations and takes no action on its own.
Runs as the app (asApp()), constrained to the granted scopes — or as the acting administrator when the console's "Run as me" toggle is on.
Is recorded in Hooks' run history (logs, result, status, timing), so the effect of any hook is reviewable after the fact.

Triggered hooks — event listeners across ten work-item event kinds, scheduled hooks, JQL-function hooks, and scripted-field hooks — fire only when an administrator has saved and enabled them; a disabled hook never runs.

Script execution model and isolation

Hooks executes administrator-authored scripts inside the Forge runtime. The execution model is the core security-relevant feature:

Curated surface only. A script runs in a function scope that receives exactly three values: jira (the curated API above), console (captured logging), and context (the event payload for triggered hooks). It is not given require, process, global, or the Forge SDK.
Admin-authored trust model (v0). Scripts are isolated via JavaScript function scope (new Function), not a separate VM. The trust boundary is that only Jira administrators can author and run scripts — the same model as established Jira scripting apps. Scripts run with the app's scopes, so an administrator writing a script is equivalent to an administrator acting within those scopes.
Hardening roadmap. A future release embeds a QuickJS-WASM interpreter so scripts physically cannot reach host APIs even within the runtime. (isolated-vm is not usable on Forge.)
Output bounds. A returned value is capped at 100 KB before storage; forEachIssue is capped at 5,000 items per run in v0 to prevent runaway iteration; run history and per-script versions are capped (50 and 20) to bound storage growth.

There is no AI, no analytics, no telemetry, and no third-party processing in this app. Nothing a script reads or writes leaves Atlassian's infrastructure.

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.

Hooks is a solo-developer product. We do not currently operate a paid bug bounty programme.

Compliance

Hooks 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; Hooks does not handle payment data)
GDPR and CCPA compliance commitments

Hooks 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 Hooks 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.