Pull Request Status Sync for Jira
Security
How Pull Request Status Sync handles access and credentials.
| Topic | Detail |
|---|---|
| Hosting | Atlassian Forge. There is no vendor-operated server or database. |
| Jira scopes | read:jira-work and write:jira-work (the write scope is used only for auto-promote transitions, reassignment and comments), read:jira-user (resolving "assign to" names on the settings page), and storage:app. |
| Egress | Only api.bitbucket.org, api.github.com and gitlab.com, declared in the manifest and enforced by Forge. |
| Code host access | Read-only, using tokens a Jira admin creates: Bitbucket, a workspace OAuth client with Pull requests: Read and Repositories: Read (never an Atlassian account password or API token); GitHub read-only Pull requests and Metadata; GitLab read_api. The app never writes to a code host. |
| Credential storage | One Forge secret per host (kvs.setSecret), encrypted at rest and deleted when the host is disconnected. It can be written only through the admin settings page and is never returned to the browser. |
| Admin actions | Settings are shown only on Jira's admin page, and the backend checks for the Jira Administer permission before every read or write. |
| User-facing data | The drift report runs its Jira queries as the viewing user, so issue security and permissions still apply. |
| Input handling | Settings are validated on the server. Values that reach JQL or Bitbucket queries are restricted to key/slug formats or escaped. Page output is HTML-escaped. |
| Webhooks | Optional. Each site gets its own URL and a random 192-bit secret. GitHub and Bitbucket deliveries must carry a valid HMAC-SHA256 signature of the body; GitLab deliveries must carry the secret token. Unsigned or wrongly signed requests are rejected before anything is read, and a delivery only triggers a check of the tickets it names, never a write on its own say-so. |
| Failure behaviour | If approvals can't be read, the gate blocks with the reason (fails closed), and auto-promote holds. |
| Writes | Nothing moves until a Jira admin adds a promotion rule, and Preview shows every decision before that. Each rule can be limited to specific projects. |
To report a vulnerability, email security@whitehatharbor.com. Security reports get a first response within 2 business days, and fixes follow Atlassian's Security Bug Fix Policy (see the SLA).