This Security Policy outlines the measures that protect your data when you use Workflow Guardrails for Jira.
2. Forge Architecture
The App is built natively on the Atlassian Forge platform:
No data egress: the App does not communicate with any external server, CDN or third-party API. Its code is bundled and served by Atlassian.
Isolated runtime: the App runs in Atlassian's isolated, managed Forge environment.
3. Scoped Permissions
The App requests only the Atlassian API scopes it needs:
read:jira-work: to read work items, children, links, comments, history, statuses and pull request information.
write:jira-work: to transition children, add audit and explanation comments, and record logged approvals in a work item property.
read:jira-user: to search people for the approver picker and show their names.
manage:jira-configuration: required by Jira for apps that provide workflow post functions.
4. Data Protection
Data in transit: all communication with Jira's APIs is encrypted with TLS.
Data at rest: any data the App keeps stays in your Atlassian site, protected by Atlassian's encryption standards.
Acts as the app: rules run as the app's own Jira user so they see every child work item, within the permissions your Jira administrators give the app's project role.
Administrator-only configuration: rules are added and configured in the workflow editor, which only Jira administrators can use.
Bounded work: up to 1,000 children are checked and 200 moved per transition; up to 1,000 comments are read for approvals.
5. Vulnerability Management
We welcome the responsible disclosure of security vulnerabilities. If you discover a potential security issue, please report it to us at the email address below.