Security

Every Lineset app is built on Atlassian Forge. Your data never leaves your Atlassian site: the apps run on Atlassian’s infrastructure, not on servers of ours, and what they store is kept in Forge storage, encrypted by Atlassian. This page says how to report a security problem and what we do when there is one.

Report a security problem

Write to us through our support site at https://sumline.atlassian.net/servicedesk/customer/portal/1 or by email at [email protected], with “Security” in the subject. Say which app, what you found and how to reproduce it. Please do not test against Jira sites that are not yours.

• We acknowledge a report within one business day.
• We rate it with CVSS and fix it within the deadlines of Atlassian’s Security Bug Fix Policy for cloud apps: critical (9.0 and above) within 10 days, high (7.0 and above) within 4 weeks, medium (4.0 and above) within 12 weeks, low within 25 weeks.
• We tell you when the fix is live.

Incident response plan

A security incident is any actual or suspected unauthorised access to, use, disclosure, change or loss of data an app handles; a compromise of an app, or of the accounts and code used to build and release it; or an app degrading Atlassian’s systems. A report above becomes an incident as soon as it shows any of these.

1. Contain. Within hours of learning of it, stop the harm: roll the app back to its last good version, turn off the affected feature, or ask Atlassian to block the app until it is fixed. Revoke any credential that may be exposed. Start a written timeline and keep it to the end.
2. Assess. Establish what happened, which Jira sites and which data are affected, over which period, and how. Our sources are the app’s Forge logs and the installation and activity logs Atlassian shares with partners for an incident.
3. Tell Atlassian within 24 hours of identifying the incident, as a P1 security incident in Atlassian’s developer support portal, and send an update at least every 6 hours until it is resolved.
4. Tell affected customers without undue delay, and within 72 hours of confirming the incident, so you can meet your own duties under GDPR. We email the technical and billing contacts on your app licence and post a notice on this page. The notice follows Atlassian’s incident communication template: what happened and when, how we found it, what we have done, what it means for your data, and anything you need to do. We write again when it is fixed.
5. Fix. Ship the fix through our normal release process (tested, staged, then released) within the deadlines above, and confirm with Atlassian that the incident is resolved.
6. Review. Within two weeks of the fix, write a post-incident review: the timeline, the root cause, and what we change so it cannot happen the same way again. Affected customers and Atlassian get a copy on request.

Information security policy

This is how we keep the apps, and the accounts and code used to build and release them, secure. It is reviewed once a year and whenever the way we work changes.

• Your data stays with Atlassian. The apps run on Atlassian Forge, not on servers of ours. They send nothing out of Atlassian and read only what the person viewing can already see. What they store is in Forge storage, encrypted and backed up by Atlassian; we keep no copies and no backups of our own.
• No AI on your data. The apps use no artificial intelligence or machine learning, and we never put your data into an AI tool.
• Access. Only the people who build and release the apps can reach the accounts that do it: Atlassian, GitHub, Netlify, Cloudflare and our analytics. Every one of those accounts has two-step verification. Every quarter we review who has access, which API tokens exist and whether each is still needed, remove what is not, and keep a written record.
• Changes. Every change is made in version control. Tests, type checks and a dependency audit run on every change. An app reaches customers only through one release process: committed and pushed code, the full test suite, deployment to a staging environment and a check there, then production.
• Dependencies. A known vulnerability in any package the apps ship fails the build. We are alerted to new advisories as they are published, and update dependencies monthly. Every release carries a software bill of materials (CycloneDX), which we review whenever it changes.
• Platform. The apps run only on Atlassian's managed Forge runtime, on a Node.js version Atlassian supports; we move to a newer one before Atlassian retires the old. The machines we build on run a supported operating system that installs security updates automatically, with full-disk encryption and its built-in malware protection on.
• Logs. The apps' logs hold no content from your Jira site, and only the apps' developer account can read them.
• Incidents. We test the incident response plan above once a year with a written exercise, and fix what it finds.
• Compliance. Once a year, and when they change, we check the apps against Atlassian's Marketplace security requirements and Security Bug Fix Policy, and against GDPR.

Past incidents

None.