Security

Architecture

ConfigRadar 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 as a Jira admin page. 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 import the audit log (hourly), take configuration snapshots (daily), compute diffs and drift, raise alerts and run retention and privacy jobs. Scheduled triggers, Jira configuration events and a queue consumer run this work asynchronously.
• Storage: Forge SQL and Forge Key-Value Store (hosted storage), on Atlassian infrastructure.
• No remotes: no Forge Remote, no Connect, no web triggers, no backend operated by Radrly, and no public REST API.

Data flow

1. The app reads the Jira audit log (30-day backfill on install, then hourly) and, once a day, the content of workflows, workflow schemes, custom fields and contexts, screens, permission schemes and project settings, through Forge as the app user. IP addresses in audit records are dropped before storage.
2. Functions compute diffs, drift and alerts and store them in Forge SQL and Key-Value Store.
3. Admins see results inside Jira. Only the signed-in user's browser and Atlassian are involved.
4. In the Advanced edition, if enabled, alerts are created as Jira issues in the project an admin chooses; Jira sends its own notifications. CSV exports are generated in Forge and downloaded by the admin. Nothing is written to Jira configuration.

Scopes

ConfigRadar requests granular read:* Forge scopes for the APIs it calls, read:audit-log:jira, personal-data reporting, and issue write scopes used only by the Advanced edition to create alert issues. It requests no manage:* scopes and cannot change workflows, schemes, fields, screens, permissions or projects. This table lists all 34 scopes in the app manifest as of 10 October 2026.

Forge scopes are the same for both editions, because they are approved once at install. The edition only decides which features run. No scope is declared with allowImpersonation: the app always acts as its own app user.

No egress

ConfigRadar declares no external hosts and makes no outbound network calls. It uses no Forge Remote, no Connect, no web triggers and no fetch to external services. There are no Slack, Teams or email webhooks: alerts stay in the app or become Jira issues, and Jira sends its own notifications. Radrly receives no customer data, and the app sends no telemetry to Radrly or any third party.

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 only user identifiers stored. IP addresses from audit records are discarded, user-management audit records are skipped, and display names are not stored. Issue content, comments and attachments are not stored.
• Retention: change history is kept for 90 days in Standard and up to 3 years in Advanced; a daily job deletes older records.
• Logs: the app logs operational status and error messages in the Forge developer console, without personal data. It does not send logs to Radrly.

Access control

• Jira admin only: ConfigRadar is a Jira admin page. Every resolver checks that the signed-in user holds the Administer Jira global permission before it reads any data.
• No Radrly backend: the app has no code path that sends your ConfigRadar data to Radrly, and Radrly operates no server that holds it.
• No configuration writes: there is no UI or API path in ConfigRadar that changes Jira configuration. The only write is creating alert issues in the project an admin chooses, in the Advanced edition.
• Safe queries: all Forge SQL queries use prepared statements, and resolver input is validated.

Data lifecycle

1. Install: the app asks for the scopes above, runs migrations in Forge SQL, imports 30 days of audit log and takes the first snapshot.
2. Use: audit entries are imported hourly and snapshots taken daily while the app is installed.
3. Retention: records older than the edition's retention period (90 days in Standard, up to 3 years in Advanced) are deleted daily, except current versions and versions used by a baseline.
4. 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

ConfigRadar does not call any external AI or LLM service. Diffs, drift and alerts are deterministic calculations over Jira configuration data inside Forge. The Advanced edition (coming soon) will include a Rovo agent: Rovo is Atlassian's own AI, and the agent will run inside Atlassian and answer from ConfigRadar data on your site. ConfigRadar sends no data outside Atlassian for it.

Compliance

Radrly does not hold its own compliance certifications for ConfigRadar 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.

ConfigRadar helps customers keep change-control evidence for their own audits (for example SOC 2 or ISO 27001 change management). That does not mean ConfigRadar itself is certified.

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

Incident response

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

Roles

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

Severity levels

Steps

1. Detect — identify and log the event from monitoring, reports, Atlassian notices or internal review.
2. Contain — stop further exposure (for example revoke access, disable a build, or take the app out of distribution where appropriate).
3. Assess — confirm scope, severity, affected sites and whether personal data is involved.
4. Notify — inform Atlassian and affected customers as set out below.
5. Remediate — ship a fix, rotate credentials if needed, and restore normal operation.
6. 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 ConfigRadar 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).
• Least privilege by design: CI and reviews treat any new scope, egress, remote or web trigger as a blocking change.

Reporting a vulnerability

If you believe you have found a security vulnerability in ConfigRadar, 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.