Security Practices

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

For context, Easy Agile User Story Maps and Easy Agile Roadmaps are delivered as 'static' add-ons for Jira. The entire product is written in Javascript and that file is delivered to the client and the product runs entirely on the client side. We chose this architecture to minimise our security footprint.

Our Security Practices should be read in conjunction with the Easy Agile Privacy Policy and License Agreement.


Jira Cloud

All of your Jira issue / project / user data is kept in your Jira Cloud instance. Your data is never stored by our add-on servers. Our addons are simple, static javascript applications which run entirely in your browser. They retrieve the data they require directly from your Atlassian Cloud instance.

Our Jira 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.

As the product is delivered as a static, client-side add-on, the requests to read, create or update Jira data are made by the account of the person using the addon. When you install the add-on you will see a new user added automatically to the Jira Software projects (e.g. Easy Agile User Story Maps for Jira (addon_com.kretar.Jira.plugin.user-story-map)) under the role 'atlassian-addons-project-access'.

We do not conduct penetration testing as our infrastructure providers are Amazon Web Services and Atlassian, and they do not permit penetration testing on their infrastructure (based upon their license and usage agreements). Having said that, we do follow the Amazon and Atlassian guidelines for security:

Analytics Data

Easy Agile captures analytics events from our products and stores these in a private analytics database hosted on Amazon Web Services in the United States of America.

No Personally Identifiable Information is included in the analytics events sent.

We do include the license Support Entitlement Number (SEN) to improve your customer support experience. For example, in the event you experience an error and raise a support request we are able to diagnose the problem quicker.

Example analytics event data we receive:

Add-on KeySENActionEvent DataTimestampVersion
com.kretar.Jira.plugin.user-story-mapSEN-XXXXXXXstorymap-rendered{"JiraVersion":"7.1.2", "eausmjsVersion":"3.0.18", "loadDuration":3447, "boardType":"scrum", "estimationType":"Story Points", "doneIssueCount":2, "issueCount":59, "epicCount":25}2017-03-20 22:54:39.488+003.6.1
com.kretar.Jira.plugin.user-story-mapSEN-XXXXXXXclicked-create-epic-button-splash
2017-03-20 22:53:22.433+001.2.3-AC
com.arijea.easy-agile-roadmapsSEN-XXXXXXXroadmap-rendered{"epicCount":10, "loadDuration":570, "JiraVersion":"7.2.6", "readOnlyMode":true, "scheduledEpicCount":0, "selectedTimelineType":"month", "themeCount":1}2017-03-20 22:38:17.322+002.8.2

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 both Jira Cloud and Server. 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 staging branch where we do final user acceptance testing before release. Once we are happy with the results we merge into the master branch which always represents what is in production.

In the case of Jira Cloud the feature is then deployed automatically and customers begin to see the new version immediately. For Jira Server we select a commit on master that contains the desired functionality, we than 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.

If you find a security vulnerability please email dave@easyagile.com (Keybase/PGP) and nick@easyagile.com (PGP/Keybase) directly.

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.

Security changes are limited to the CTO and CEO and are conducted together in person.