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. As a result we do not store any data or credentials on our servers. We chose this architecture to minimise our security footprint.

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 provider is Amazon Web Services and they do not permit penetration testing on their infrastructure (based upon the license and usage agreement). Having said that, we do follow the Amazon guidelines for security.

Analytics Data

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

No Personally Identifiable Information is included in the analytics events sent. We do include the Support Entitlement Number (SEN) to improve the customer support experience (in the event of an error we are able to diagnose it quicker).

An example of the analytics 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. 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 the pull request. Their colleagues review the code for consistency, sanity, and against the acceptance criteria on the story. There is usually a few comments of things to consider, tidy up, change and these are 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 the work makes sense from a customers perspective. This often turns up UI/UX improvements for the story which are also 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. For JIRA Server we select a commit on master that contains the desired functionality, tag it and perform a manual release to Atlassian Marketplace.

On every commit to the development branch unit tests are automatically run. Pre-commit hooks exist on the master branch which prevent any commit that hasn't gone through a pull request and been approved.

All features are fully tested before release. There is acceptance and unit tests, and we have a high level of test coverage. Unit tests are run on every commit to the repository.

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 providers.

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