Security – Rule Keeper for Jira
Architecture
- Built on Atlassian Forge and eligible for Runs on Atlassian: all compute and storage run on Atlassian's infrastructure, there are no external hosts, no remotes and no data egress.
- Data is stored in Forge hosted storage of your site and follows its data residency.
Access control
- The admin page and every backend function check, on the server, that the calling user holds the Jira Administer Jira global permission. Other users get no data.
- The app reads Jira data as the administrator who opened it, so counts respect that administrator's permissions.
- Permissions requested from Atlassian, and why:
| Scope | Why |
|---|---|
read:jira-work |
Count issues for the cost forecast; check the caller's admin permission |
read:jira-user |
Check whether rule actors and authors are active |
storage:app |
Store snapshots and settings in your site |
report:personal-data |
Weekly personal data report to Atlassian |
Optional sync endpoint
- A Forge web trigger receives snapshots from the optional sync tool.
- Each request must be signed with HMAC-SHA256 using a secret that a Jira administrator generates in the app. The secret is stored encrypted, shown once, and can be rotated or revoked at any time.
- Requests older than 5 minutes or replayed are rejected. Payloads are validated and size-limited. Responses are fixed and reveal no data.
Development practices
- Automated tests (over 100) cover parsing, cost calculation, lint, access control, the sync endpoint and privacy handling.
- A security review runs before every release (see release notes).
- Dependencies are kept current; known issues in Atlassian-provided UI packages are tracked until Atlassian publishes fixes.
Reporting a vulnerability
E-mail support@687.monster with the subject "Security". We acknowledge within 2 business days and follow Atlassian's Marketplace security requirements for fix timelines.