License Sentinel security
1. Summary
License Sentinel is a Forge app. It runs on Atlassian's platform, keeps its data in Atlassian's Forge storage, and has no servers, databases or public endpoints of ours. That removes most of the attack surface a normal web service has, and it means many of the strongest protections (encryption at rest, network security, separation between customers, the runtime) are provided and operated by Atlassian. This page says which protections are Atlassian's, which are ours, and how to report a problem.
2. How the app is built
- No servers of ours. Functions run on Atlassian's Forge runtime. There are no web triggers and no remote back ends, so nothing on the internet can call the app directly. The only entry points are the admin page, which Atlassian shows only to site admins, and two scheduled jobs.
- No outside connections and no credentials. The app's manifest has no outbound access at all, and the app asks no one for a password, token or API key. Everything it reads comes from Jira through Forge.
- Little data. The app stores account IDs and the dates they were last seen doing something in Jira. It stores no names, no emails and no issue content. See the privacy policy.
- Least privilege. The app requests four permissions:
storage:app,read:jira-user(to list the site's people and show their names to the admin looking at the page),read:jira-work(to read who created, commented on, logged work on or changed issues, and when) andreport:personal-data(for Atlassian's privacy reporting).read:jira-workis the widest of them, and the app uses it only to read an author and a time from each item. Atlassian's granular scopes for the same calls would need about fourteen separate scopes and are not recommended by Atlassian where a classic scope fits, so the classic scope stays.
3. Who is responsible for what
This follows Atlassian's shared responsibility model for Forge.
| Area | Atlassian | Us | The customer |
|---|---|---|---|
| Authenticating users before the app runs | Yes | ||
| Encrypting stored data at rest, TLS in transit | Yes | ||
| Keeping customers' storage separate | Yes | Not keeping customer data in shared memory | |
| Runtime, network, infrastructure security | Yes | ||
| Application logic, input validation | Yes | ||
| Dependencies and framework updates | Atlassian's packages | Our own use of them | |
| Not logging personal data | Yes | ||
| Vulnerability fixes in the app | Yes | ||
| Who is a site admin, and which projects the app is allowed to browse | Yes |
4. How data is protected
- Encryption. Stored data is encrypted at rest by Atlassian. Traffic to and from Atlassian uses TLS. The app stores no secrets, because it holds no credential.
- Issue content is not kept. Jira returns comments and history whole, so the text reaches the app's function for the moment it takes to read the author and the time. It is not stored, logged, shown or sent anywhere, and only an account ID and a date are kept.
- No personal data in logs. The app logs counts, timings and HTTP status codes only. It never logs account IDs, dates, names, issue content or Jira's own error text.
- Injection and unsafe input. Every value that goes into a database query is a bound parameter. Page sizes and offsets are checked to be whole numbers first. The stale threshold, the seat price and the organization ID must match fixed patterns. A keep reason can only be one of a fixed list, and an end date is worked out by the app, never taken from a request. Exported CSV files are quoted and protected against spreadsheet formula injection.
- Permissions of the person using the page. The list of people and the display names are fetched as the admin viewing the page, so Jira applies that person's own permissions. The scheduled scan has no person present, so it acts as the app and can read only the projects the app is allowed to browse. Only account IDs and dates are kept from it, and the dashboard is shown only to site administrators. An administrator could in principle notice that the date or status of an account changed because of activity in a project they cannot browse. No content from such a project is ever shown.
- Customer separation. Forge storage is separated per installation. We also avoid keeping customer-specific data in memory that a warm process could hand to another customer.
- Licensing. When an installation is unlicensed, the account list, settings and export are refused by the app's back end as well as hidden on the page.
- Data minimisation and removal. People who leave the site are removed automatically. Accounts that Atlassian reports as closed are erased at the next weekly privacy check. An administrator can delete everything the app stored with one button, which also stops the app reading anything until they start it again.
- Nothing is read until an admin agrees. The app reads no issue data until an administrator presses Start collecting.
5. How we build and maintain it
- Tests. The app has more than 430 automated tests. The rules that matter most (how an issue becomes an account and a date, account status, the scan and people loops, removal of departed accounts, the privacy report, licensing, the keep list, CSV output) are also checked by breaking the code on purpose and confirming the tests notice.
- Review before release. Every change is checked by the test suite and Forge's linter before deployment, and deployed first to a development environment.
- Secrets. The app handles none. No keys or tokens are kept in the source code or its history, which has been scanned.
- Dependencies. We use Atlassian's Forge packages and keep them current. A dependency audit currently reports nine advisories (one moderate, eight high). All of them come in through Atlassian's own
@forge/reactand@forge/bridgepackages, from a text-editor library and a markdown library inside Atlassian's user-interface packages. The app does not use those editor or markdown features, and no advisory affects our own code or any other package. We cannot fix them ourselves, we track them, and we update when Atlassian publishes new versions. - Maintenance. The app is kept up to date with the supported Forge runtime. We do not run end-of-life runtimes.
6. What customers should do
- Press Start collecting only when you are ready. Nothing is read before that.
- Read the results as people to review. The app estimates activity from what people did in Jira. People who only view issues leave no trace, so a stale account is not proof that someone does not use Jira.
- Check which projects the app can browse. It reads only projects its permissions allow. The dashboard names projects you can browse and the app cannot. If you want one counted, add the app to that project's permissions.
- Limit who is a site administrator. The dashboard shows account IDs and dates to site administrators.
- Delete all data, or uninstall the app, to remove its data. Atlassian deletes the data of an uninstalled app after its retention period.
7. Reporting a vulnerability
If you think you have found a security problem in License Sentinel, please tell us at hello@alzhangroupllc.com. Please include what you found and where, how to reproduce it, and what you think the impact is.
We ask that you give us a reasonable time to fix the problem before telling anyone else, that you do not access or change data that is not your own, and that you do not disrupt anyone's service.
What you can expect from us:
- an acknowledgement within 5 business days
- an assessment and a plan within 10 business days
- fixes within the timelines Atlassian sets for Marketplace apps: critical 10 days, high 4 weeks, medium 12 weeks, low 25 weeks from when we confirm the problem
- credit in our notes if you want it
We do not currently run a paid bug bounty program. Atlassian runs one for the Forge platform itself.
8. If something goes wrong
We have a written incident response plan. If a security incident affects customer data, we will notify Atlassian within 24 hours, as the Marketplace requires, and notify affected customers without undue delay, aiming for within 72 hours of confirming the incident. We will tell customers what happened, what data was involved, what we have done, and what they should do.
9. Compliance and certifications
License Sentinel does not currently hold a compliance certification such as SOC 2 or ISO 27001. It relies on Atlassian's Forge platform for hosting, and Atlassian publishes its own certifications. We have not yet completed a CAIQ Lite questionnaire.
10. Contact
Security and support: hello@alzhangroupllc.com
Alzhan Group LLC, Houston, Texas, United States