Security – AccessRadar for Jira

Architecture

AccessRadar is built entirely on Atlassian Forge and declares no remotes and no external permissions, which is what Atlassian's Runs on Atlassian programme requires. The badge itself is awarded by Atlassian. The app has no servers of its own.

User interface: Forge Custom UI (React, Atlassian Design System) shown inside Jira administration. It only talks to the app's own Forge functions. The manifest asks Atlassian only to allow inline styles for it; it allows no external scripts, frames or network access.
Logic: Forge functions that read projects, permission schemes, roles, groups and users, resolve effective access, and run snapshot and privacy jobs. A scheduled trigger and a queue consumer collect snapshots asynchronously.
Storage: Forge SQL and Forge Key-Value Store (hosted storage), on Atlassian infrastructure.
No remotes: no Forge Remote, no Connect, no backend operated by Radrly, and no public REST API.

Data flow

The app reads projects, permission schemes, project roles and actors, groups, application roles and users from Jira through Forge (as the app user, with optional impersonation only when an admin enables a collector fallback).
Functions resolve effective access and store snapshot and review data in Forge SQL and Key-Value Store.
Admins see results inside Jira. Only the signed-in user's browser and Atlassian are involved.
Exports (CSV/PDF) are generated in Forge and downloaded by the admin. Nothing is written back to Jira configuration or issues.

Scopes

AccessRadar requests granular read:* Forge scopes for the APIs it calls, plus personal-data reporting. It requests no write or manage scopes.

Scope	Reason
`read:project:jira` and related project reads	List projects and project metadata needed to map schemes and roles.
`read:permission-scheme:jira`, `read:permission:jira`	Read permission schemes and grants (classic and team-managed).
`read:project-role:jira`, `read:group:jira`, `read:user:jira`, `read:application-role:jira`	Resolve who holds access through roles, groups and application roles.
`read:avatar:jira` and other listed project catalogue reads	Support project listing and UI display as required by the Jira APIs used.
`storage:app` (via Forge SQL / KVS)	Store snapshots, reviews and app settings in Forge hosted storage.
`report:personal-data`	Report stored Atlassian account IDs to Atlassian's personal data reporting API and erase or anonymise them when Atlassian reports an account closed or updated.

Some read scopes are declared with allowImpersonation so an admin can optionally designate a collector identity if the app user is later restricted. Impersonation is not used to write data.

App user vs scopes. Atlassian may add the AccessRadar app user to admin groups so directory and scheme reads succeed. That can look alarming in an access audit. The Forge scopes still block writes: the app cannot create or edit issues, change schemes, or modify users and groups. Control probes that attempt issue search fail with a scope mismatch.

No egress

AccessRadar declares no external hosts and makes no outbound network calls. It uses no Forge Remote, no Connect and no fetch to external services. Radrly receives no customer data, and the app sends no telemetry to Radrly or any third party. The only outbound requests in the code are authenticated calls to Jira through Forge.

Requests to Jira use Forge's authenticated platform APIs. The app does not handle passwords, personal access tokens or shared secrets.

Data protection

At rest: data is stored in Atlassian's Forge hosted storage, which Atlassian encrypts at rest.
In transit: traffic between the browser, Jira and Forge uses TLS, managed by Atlassian.
Data residency: app data follows the data residency location of your Jira site. Radrly does not store data anywhere else.
Minimisation: Atlassian account IDs are the primary user identifiers. Display names may be stored so reviews remain readable. Issue content, worklogs, comments and attachments are not stored. Email addresses are not stored as a primary identifier.
Review integrity: signed reviews record a SHA-256 hash of the review package so evidence can be verified later.
Logs: the app logs operational status and error messages in the Forge developer console. It does not send logs to Radrly.

Access control

Jira admin only: AccessRadar admin pages require Jira administer permission. Resolvers check the caller's permissions before returning data.
No Radrly backend: the app has no code path that sends your AccessRadar data to Radrly, and Radrly operates no server that holds it.
Read-only surface: there is no UI or API path in AccessRadar that mutates Jira configuration or issues.

Data lifecycle

Install: the app asks for the scopes above and runs migrations in Forge SQL.
Use: snapshots and reviews accumulate while the app is installed.
Delete in the app: admins can delete AccessRadar data where the product provides data controls (see docs as features ship).
Uninstall: the Forge platform soft-deletes the data and destroys it at the end of the retention period in Atlassian's SOC 2 report (a reinstall within 21 days can be relinked to the old data). Radrly keeps no copy.

See the Privacy Policy for details.

AI statement

AccessRadar does not call any external AI or LLM service and does not include a Rovo agent in the current product scope. Access resolution and risk indicators are deterministic calculations over Jira permission data inside Forge.

Compliance

Radrly does not hold its own compliance certifications for AccessRadar at this time. Atlassian's platform certifications cover Forge hosting. We do not claim them as our own. We have not yet completed a CAIQ Lite questionnaire, and do not run a bug bounty program yet. Every change goes through automated checks (formatting, linting, type checking, unit tests and Forge lint) before it is deployed.

AccessRadar is designed to help customers produce access-review evidence for their own SOC 2 and ISO 27001 programmes. That does not mean AccessRadar itself is certified.

For data protection terms, see the Privacy Policy and the DPA.

Incident response

Radrly maintains an incident response plan for AccessRadar. The plan is tested at least once a year.

Roles

Incident lead: Marcin Nowak
Security contact: marcin@radrly.com

Severity levels

Level	Meaning
Critical	Active exploitation, confirmed data breach, or complete loss of confidentiality, integrity or availability for customer data.
High	Serious vulnerability or security event with a realistic path to customer data exposure or major service disruption, not yet confirmed as a breach.
Medium	Limited impact security issue, constrained exposure, or a vulnerability that needs a timely fix but does not indicate an active incident.
Low	Minor hardening gap, informational finding, or event with negligible customer impact.

Steps

Detect — identify and log the event from monitoring, reports, Atlassian notices or internal review.
Contain — stop further exposure (for example revoke access, disable a build, or take the app out of distribution where appropriate).
Assess — confirm scope, severity, affected sites and whether personal data is involved.
Notify — inform Atlassian and affected customers as set out below.
Remediate — ship a fix, rotate credentials if needed, and restore normal operation.
Post-mortem — document root cause, timeline and follow-up actions so the same class of issue is less likely to recur.

Notification commitments

After confirming a security incident, we notify Atlassian via ECOHELP / AMS and affected customers within 72 hours (aligned with GDPR Article 33 where personal data is involved).
Critical vulnerability fixes follow the timelines in the Atlassian Marketplace security bug fix policy.
We use Atlassian's incident and vulnerability notification templates when notifying Atlassian and customers.

Secure development

Change control: changes reach main only through pull requests; direct pushes to main are not used for product work.
Access: MFA is required on GitHub and Atlassian accounts used for AccessRadar development and publishing.
Dependency and code scanning: Dependabot, npm audit and CodeQL run on the repository to catch known vulnerable packages and common code issues.
Secrets: CI credentials and tokens live in GitHub Actions secrets and are rotated periodically. Secrets are not committed to the repository.
Design review: significant changes are reviewed against the OWASP Top 10 for the Forge / Custom UI threat model (for example injection, broken access control, SSRF and security misconfiguration).
Read-only by design: CI and reviews treat the introduction of write scopes or egress as a blocking change.

Reporting a vulnerability

If you believe you have found a security vulnerability in AccessRadar, please tell us privately so that we can fix it before it is made public.

Email: marcin@radrly.com

Please include:

A description of the issue and its potential impact.
Steps to reproduce, or a proof of concept.
The affected app version and Jira site (use a test site where possible).
Your contact details, if you want credit.

What to expect: we will acknowledge your report within 2 business days, keep you informed, and tell you when it is fixed. Please give us a reasonable time to fix the issue before sharing details, and do not access, change or delete data that is not yours, or disrupt other customers. Good-faith research that follows these rules will not be pursued legally by Radrly.

For general bugs and questions, use Support instead.