Security policy

Last updated: 26 October 2026

Scope

This policy describes how RETEK ("we") keeps Vouchline Access Reviews for Jira ("Vouchline", "the app") secure: who can change the app, how changes are made, how we handle reported vulnerabilities, and what we do if a security incident happens.

It is written for a company of one. RETEK is one person, who develops, releases and supports the app. Nobody else has access to the accounts listed below. This policy describes what that person actually does; it promises nothing a one-person company cannot keep.

How the app limits what can go wrong

The design of the app removes most of the usual risks before any procedure is needed:

• No infrastructure of our own. Vouchline runs entirely on Atlassian Forge. We operate no servers, databases or cloud accounts that hold customer data.
• No data leaves your Atlassian site. The app makes no outbound network calls: its manifest declares no external fetch and no remotes, and it loads nothing from outside Atlassian.
• Read-only. The app requests no write scopes and changes nothing in Jira. It reads permission metadata only — no work items, comments, attachments or worklogs.
• Data stays in Forge hosted storage of your installation. We have no access to it in the ordinary operation of the app.
• Administrative functions check permissions on the server side. Every administrative function of the app denies access unless Jira confirms that the user is an administrator; a reviewer can read only the items assigned to them. See Reviewers and access.

What the app reads and stores is listed in the privacy policy and in What Vouchline reads.

Accounts and access

The accounts that can change the app or speak for it are:

For each of them:

• Two-factor authentication is required. An account without it is not used to work on the app.
• Every password is unique and kept in a password manager.
• Accounts are personal and not shared. There are no other users, and no access is given to contractors.
• API tokens are created only when a tool needs one, are never written into the source code, and are revoked when no longer needed.

Quarterly access review

Once a quarter — in January, April, July and October — we review the accounts listed above. The review takes about fifteen minutes and checks:

• that two-factor authentication is still on for each account;
• who has access: members of the Atlassian developer space and partner account, collaborators on the GitHub repository, users of the OVHcloud account and of the mailboxes — the expected answer is one person;
• active sessions, connected applications and API tokens, revoking any that are not recognised or no longer needed.

The date of each review and anything changed as a result are recorded in an internal access review log.

Development and release

• The source code is kept under version control in a private repository, so every change can be traced and reverted.
• Before every commit, the complete automated test suite, the linter and the build must pass. A change in behaviour and the test for it are committed together.
• A new version is deployed to a separate development site and checked there before it is deployed to production.
• Before every release, npm audit is run on the app's dependencies. Known vulnerabilities are fixed, or assessed and recorded as not exploitable in the app, before the release goes out.
• No secrets in code: the repository contains no passwords, API tokens or keys. The app itself needs none, because it calls no external service.
• New dependencies are added only when necessary, because each one becomes part of what runs in your Atlassian site.
• Any change to the app's scopes is a deliberate decision. It is visible to you: Atlassian asks a site administrator to approve new scopes before an installation is upgraded.

Reporting a vulnerability

Report security vulnerabilities to security@retek.app. Please include the steps to reproduce the issue and, if you can, the affected version. Do not include personal data or evidence packages from your site.

• We acknowledge a report within two business days.
• We assess its severity with CVSS and fix it within the timeframes of the Atlassian Marketplace security bug fix policy for cloud apps. On the date of this policy these are:

• Vulnerabilities reported to us by Atlassian, including through the Marketplace bug bounty program, are handled the same way.
• A fix that does not change the app's scopes reaches every installation automatically when it is deployed.
• We tell the reporter when the issue is fixed. Where customers need to act or should know about a vulnerability, we notify them using Atlassian's vulnerability notification template.

Security incident response

We follow the Atlassian Marketplace app security incident management guidelines. A security incident is any actual or suspected unauthorised access to, disclosure, modification or destruction of customer data, or a security compromise of the app or of the accounts that control it.

When we become aware of a possible incident:

1. Investigate. Establish what happened, the root cause, how long the issue existed, whether customer data could have been affected, and which customers.
2. Notify Atlassian promptly and no later than 24 hours after becoming aware of the incident, by raising a P1 security incident ticket with Atlassian's developer support, and send updates at least every 6 hours while the incident is being remediated.
3. Contain. Stop further impact: revoke compromised credentials and tokens, deploy a fix or roll back to an earlier version from version control, and, together with Atlassian, temporarily hide the app from the Marketplace if that is needed.
4. Fix the cause. Put in place technical and organisational measures that prevent a similar incident.
5. Notify affected customers, using Atlassian's security incident communication template, where possible within 72 hours of identifying the incident. Your organisation is the controller of the data the app holds in your site; we give you the information you need to meet your own notification obligations.
6. Review. After the incident is resolved, write down what happened, what was done and what changes as a result, and submit the findings to Atlassian through the incident ticket.

The security incident contact in our Atlassian Marketplace partner account is kept up to date.

Review of this policy

We review this policy once a year, in October, and also after a security incident or a significant change to the app. Changes are published on this page and the date above is updated.