Security policy

Last updated 3 August 2026 · Applies to Group Blast Radius and any other Lintelworks app for Atlassian. This is our partner security policy; how we handle data is set out separately in Privacy.

Lintelworks is a small, independent app partner. We would rather tell you exactly what we do and do not have than imply a security programme we do not run. This page is written to be checked, not to be reassuring.

Security by architecture, not by promise

Most of what protects you here is structural rather than procedural. Our apps are built on Atlassian Forge and run inside Atlassian's own cloud. We operate no servers, no databases and no infrastructure that touches your data, so the usual questions about our hosting, our network perimeter and our backups have the same answer: there isn't one to attack.

• No egress. The app declares no external network access. Forge blocks any request to a host that is not declared, and we declare none — so the app is not technically capable of sending your data anywhere.
• No storage. The app has no database and uses no persistent storage. Every report is computed on request and discarded. There is no customer data at rest to breach.
• Read-only. The app contains no code that creates, updates or deletes anything in your site. A defect can produce a wrong answer; it cannot damage your configuration.
• Minimal supply chain. The runtime dependency set is Atlassian's own Forge packages plus React. We add no third-party libraries for convenience.
• Small, readable codebase. Around 700 lines of application code in total, which is itself a control: it can be reviewed end to end.

One consequence worth stating plainly: because the app runs on Forge, Atlassian owns the runtime, the platform patching and the tenancy isolation beneath us. Atlassian's own security posture is documented at atlassian.com/trust.

Reporting a vulnerability

Write to hello@lintelworks.net with "security" in the subject line. The mailbox is read by the person who wrote the code.

• We acknowledge security reports within 2 business days.
• We will tell you whether we consider it a vulnerability, and why, within 5 business days of acknowledging it.
• We ask for coordinated disclosure: please give us 90 days before publishing, or less if we have already shipped a fix.
• We do not run a paid bug bounty and cannot offer a reward. We will credit you if you want to be credited.

Please do not include customer data, credentials or screenshots containing either in a report. We do not need them and would rather not hold them.

Vulnerability management

We track security advisories for the Forge platform and for the small set of packages we depend on, and we review dependency advisories before each release. Because the dependency surface is deliberately tiny, patching is a matter of updating Atlassian's own SDK rather than chasing a large transitive tree.

Our remediation targets, measured from the point we confirm an issue:

Severity is assessed against the actual exposure of a read-only, zero-egress, zero-storage app — we will not inflate or deflate a rating to make the table look better, and we will explain the reasoning to any customer who asks.

How we handle a security incident

We hold no customer data, so the classic breach scenario does not apply to us. The realistic incidents are narrower, and we plan for those:

1. A defect that produces a materially wrong result. We treat this as our highest-severity class of issue, above conventional vulnerabilities, because the entire purpose of the app is to be trusted before an irreversible change. Confirmed, we fix it, ship it, and notify affected customers.
2. Compromise of a publishing or development credential. Response is: revoke the credential, rotate authentication, review the deployment and version history for unauthorised changes, and — if any unauthorised version could have reached customers — notify affected customers and Atlassian immediately.
3. A platform-level issue reported by Atlassian. We follow Atlassian's guidance and timelines and relay anything customer-affecting.

In all cases we aim to make an initial notification to affected customers within 72 hours of confirming a security incident that affects them, via the contact address on record and, where appropriate, through Atlassian. Notification will say what happened, what we know, what we do not yet know, and what we are doing — including when the honest answer is that the investigation is still open.

Development and access controls

• Development, publishing and billing accounts are protected by multi-factor authentication.
• Access to the developer and Marketplace accounts is limited to the operator; there are no shared credentials and no standing third-party access.
• The app requests the narrowest scopes we could make work. Where a scope looks broader than it should — manage:jira-configuration — we document exactly why in Privacy rather than quietly narrowing what the app checks.
• Changes to the logic that decides whether a group matches are covered by unit tests, which run before release. That code path is the one that can silently produce a false "clear", so it is the one we test hardest.
• Releases go through Atlassian's Marketplace approval process, which includes their own review of the app and its declared permissions.

Logging

When a request to Jira fails, the app logs the failed request so that a section reported as not checked is diagnosable afterwards. That log line can include a group name passed as a query parameter. These logs are written to Atlassian's Forge logging within your own environment — no logs are sent to us or to any third-party logging service, because the app has no external network access.

What we do not have

Stated deliberately, because a security policy that omits this is not much use to someone assessing us:

• No SOC 2 report and no ISO 27001 certification.
• No third-party penetration test of the app.
• Not currently enrolled in the Atlassian Marketplace Bug Bounty programme.
• No 24/7 on-call rotation. We are a small operation and respond in business hours.
• No separate peer reviewer — the code is written and reviewed by one person, which is why the architecture is constrained the way it is and why the risky logic is covered by tests.

If any of that changes, it changes here first, with a date on it.

Business continuity

The app holds no state, so there is nothing to restore. Availability depends on Atlassian's Forge platform; if Forge is down the app is unavailable, and no customer data is at risk while it is. Uninstalling the app removes it cleanly and leaves nothing behind, because there was never anything stored.

Contact

Security matters, questionnaires and assessment requests: hello@lintelworks.net. Lintelworks is operated by a US limited liability company.