This document was last modified on March 22, 2022.

The Move Work Forward team takes security very seriously. We know we're not infallible and we are always working to improve our security practices. Below we detail our current practices.

Our Security Practices should be read in conjunction with the Move Work Forward Privacy Policy and License Agreement.

Cloud products

All of your Jira issues/projects, Confluence pages or any other user data is kept in your Jira, Confluence or Bitbucket Cloud instance. Your data is never stored by our services. We stored only configuration data you enter and different IDs or keys to fulfil the functions of our Apps. Apps of Move Work Forward retrieve the data they require directly from your Atlassian Cloud instance.

Our Cloud versions require the following Atlassian Connect Permissions (Scopes): Read, Write, Delete and Project Administration. Project Administration is needed for the creation and updating of Versions.

Programs we participate in.

  • Atlassian Cloud Fortified. Our reliability and support are certified Cloud Fortified by Atlassian.
  • AtlassianCloud Security. Our security is verified by Atlassian's reviewed Cloud security program.
  • Bug bounty program. Over 100 security researchers scan our apps regularly for vulnerabilities.
  • GDPR compliant. Compliant with EU regulation 2016/679 and all other applicable data protection laws.

Guidelines for security

We follow the Atlassian guidelines for security:

As an infrastructure backbone we use AWS.

Analytics Data

Move Work Forward captures analytics events from our Cloud products and forwards events to Segment and Amplitude. We do not store any PII data. We do store data required our Apps to work (mostly different identifiers).

Data transfer

All data transfer between the user’s browser and the user’s site happens securely via HTTPS.

Data backup and recovery

We use AWS Backup and AWS DynamoDB Point-In-Time recovery technologies from Amazon Web Services to provide data backup and recovery capabilities.

Server and Data Center products

Our server and data center products are following our security development process. We are following security code reviews and following security best practices.

Development Workflow

We have a backlog that is ordered in terms of our vision for the product coupled with key customer feature requests. Team members pull stories from the backlog as capacity allows. Typically their first step is to write tests to assert the behaviour we expect. From there they will write code to make tests pass, and then refactor as needed.

When a team member is ready for code review they add two of their colleagues to a pull request. Their colleagues review the code for consistency, sanity, and against the acceptance criteria of the user story. There are usually a few comments of things to consider, tidy up or change, and these are then incorporated.

During the code review we also begin user acceptance testing of the functionality in the host product. At this point we're trying to ensure that what we deliver makes sense from a customers perspective. This often turns up UI/UX improvements for the story which are then subsequently included in the pull request.

Once the pull request has been approved the development branch is merged into our master branch where we do final user acceptance testing before merging to release branch and releasing the packages.

In the case of Cloud products the feature is then deployed automatically and customers begin to see the new version immediately. For Server and Data Center host products we select a commit on master that contains the desired functionality, we tag that with a version number and perform a manual release to Atlassian Marketplace.

On every commit to the development branch unit and functional tests are automatically run. Pre-commit hooks exist on the master branch which prevent a merge in the event a pull request has not been approved or tests are not passing.

Bug Bounty

We do not offer a bug bounty today. If you find a bug please raise a support request.

Infrastructure Access

Automation and monitoring means that team members do not require access to staging or production infrastructure.

All team members use 1Password to maintain a randomly generated password for each service, plus Two Factor Authentication for accessing our infrastructure providers.

Production access and security changes are limited to the CTO and CEO only.