Security

Lacre stores its customers' change-control evidence, so a security flaw in the app is the worst thing that can happen to it. This page says how to report one, what we do when we receive it and what data the app stores.

How to report a vulnerability

Write to security@lacreapp.com with:

• what you found and what it allows (to see or change what, and with which Jira account or permissions);
• the steps to reproduce it, on your own Jira site;
• the Lacre version, shown on the Jira site's app management page, and the browser, if it matters.

We ask you to:

• test only on a Jira site of your own or a test site, with fictitious data, never on another organisation's site;
• not access, copy or delete data that is not yours beyond what is needed to show the flaw, and tell us if you did;
• not run denial-of-service or load tests against Jira or Forge;
• not publish the details until the fix is available or 90 days have passed since your report, whichever comes first; if you need more time or less, let us talk.

A flaw in Jira, Forge or another part of the Atlassian platform, rather than in Lacre, is reported to Atlassian through its Bugcrowd programme. Lacre has no bounty programme.

What we do when we receive it

1. Acknowledgement within 2 business days (Monday to Friday, Madrid time), with who is handling it and, if already possible, a first assessment.
2. Severity assessment with CVSS and, above all, with what it allows to be done with a customer's evidence.
3. Fix within these times, counted from when we confirm it:

No time goes beyond those of Atlassian's security bug fix policy for Marketplace apps (10 days for critical, 4 weeks for high, 12 for medium and 25 for low).

4. Notice: we tell you when the fix is in production. If the flaw exposed customer data, we report it to Atlassian within 48 hours, as the Marketplace partner agreement requires, and to the affected customers, and we record it on the status page. If you wish, we credit you in the release notes.

What data Lacre stores

Lacre stores only what it needs to seal and verify. It identifies people by their Atlassian account identifier (accountId), never by their name or email address, and asks Jira for the name every time it shows one. What it does store as it is, is what gets sealed from the issue (the summary, the description, the values of the chosen fields) and the checklist texts, which may name someone if that is how they were written; fields that store people are not offered among the fields that can be chosen.

• Seals: the sealed record (the state of the sealed issue, with the type, summary, status, labels, components, versions, priority, resolution, the date it was last updated, the fields chosen by the project's administrators and the accountId of the assignee and the reporter; the checklist with who ticked each item and when; the risk level, the approval, who signed and when) and what accompanies it (the keys and ids of the issue and the project, the hash, the app version).
• The description of each sealed issue, as it was when sealed, apart from the record (which only carries its hash), up to 200 KiB. It is issue content and may contain names and mentions.
• Checklist ticks on an issue not yet sealed: which items are ticked, by whom and when. They are deleted when the issue is sealed.
• Alterations: the first change Lacre records after each seal: which fields of the issue changed and when, without who.
• Each project's settings (the checklist, the roles, the fields, the language, and who saved them last and when) and the activity log of the settings page: who (accountId) changed the settings, exported, prepared an evidence sheet or deleted the data, and when.
• Deletions in progress: while a project's data is being deleted, since when and who (accountId, up to twenty) is carrying it out. It is removed when the deletion finishes.
• Installation data: when Lacre was installed and with which version, with no personal data.

The app's technical logs (Forge's) carry result codes, project and issue keys, seal and field identifiers, counts and the licence type and status, never names, email addresses or issue content.

Where and for how long

• Where: in the app's storage on Forge, Atlassian's app platform, kept separately for every Jira site that installs Lacre, on Atlassian's infrastructure. Lacre has no servers of its own and sends no data anywhere outside Atlassian; it uses no analytics or cookies either. Each seal is also copied to a property of its issue (lacre.seal.<hash>), which Jira keeps with the issue.
• For how long: while the app is installed, unless a project's administrator deletes its data from Lacre's settings. After uninstalling, Atlassian keeps the storage for 28 days and then deletes it; the copies of the seals in the properties stay on the issues until they are deleted in Jira. Deleting a project's data leaves the record of the deletion in the activity log (who, when and which project), the project's settings (back to the defaults, with Lacre disabled) and the seals that are not only the project's (those of issues Jira now places in another project, and those before a seal of the same issue made in another project, so as not to break its chain), until the app is uninstalled.
• Who sees it: the people on your Jira site, according to their permissions. We have no access to the storage or the issues of any installation: we only see the technical logs described above, and support never asks for access to the site, issue content or exports.

Permissions it asks for

No permission to leave Atlassian or to administer the site.

How it is built

• Every action by a person checks in Jira, with the account of whoever does it, that they may do it: see the issue to seal it, have the role the project requires to seal or approve, administer the project for the settings page. Some operations are done by the app with its own identity (storing the copy of a seal on its issue, recording an alteration, finding which issues belong to a project today when deleting its data), always after checking the person when there is one behind them.
• Everything that comes from the browser or from Jira is validated before it is used, and whatever is shown on screen is shown as text.
• Dependencies are pinned to an exact version and checked for vulnerabilities on every change and every week.
• Every change goes through automated tests, a code review and a security review before it is merged, and every version is tested in a separate environment before it reaches customers.
• Seals can be verified without Lacre: how to verify a seal.