This page applies only to Awesome Graphs for Bitbucket Data Center and does not apply to Awesome Graphs for Bitbucket Cloud. You can read about our security practices in regards to Awesome Graphs for Bitbucket Cloud here.

Overview

In partnership with Atlassian, Stiltsoft is running a public bug bounty program on Bugcrowd which helps detect security vulnerabilities faster and increase the overall security level for customers.

The Awesome Graphs for Bitbucket app works within the client's Bitbucket instance and does not send any data outside. We also do not collect or transmit any in-app analytics or usage data. 

If you have questions or feedback regarding security with Awesome Graphs or would like to report a security vulnerability, please send an email to support@stiltsoft.com or create a request in the support system.

Secure development

To identify vulnerabilities in our code, the team uses the following practices:

  • All code changes undergo static analysis with SonarQube when a pull request is created. This practice helps to identify potential errors and vulnerabilities in the code. If static analysis detects a problem, the pull request cannot be merged until all issues are fixed.
  • Additionally, all code changes go through a mandatory code review process. At least two people must approve the pull request for it to be merged.
  • We use Snyk to identify vulnerabilities in our application's dependencies after each pull request merge. Additionally, Snyk performs dependency checks on a weekly basis. We also use Snyk IaC to scan our infrastructure code for potential security issues.

Product security

Source code protection

The application does not read or process repository code.

Like other Bitbucket Data Center apps, Awesome Graphs works inside Bitbucket's JVM, thus, it potentially may access all Bitbucket resources, including all database tables, repository source code, and more. Despite such permissions, our app solely reads metadata from commits and pull requests for its operation and does not modify, add, or delete data in Bitbucket in any way. All the aggregated data is available to authorized users only.

Commit and pull request metadata

Our app relies on commit metadata to generate graphs and reports. This metadata is extracted from Git repositories and stored in dedicated tables of the Bitbucket database. Our app's table names have the prefix AO_6292E3_GRAPHS_. Access permissions to the app tables are identical to other Bitbucket tables.

The process of storing commits is called "indexing." During indexing, the following commit data from Git repositories is read and stored:

  • Author's name and email address
  • Commit hash and hashes of parent commits
  • Commit creation date (author date)
  • The number of added and deleted lines of code per file in the commit is read and then filtered depending on the status of the Lines of Code setting. The total sum of added and deleted lines of code is then saved into the database.

The app uses the following Git commands: git log, git diff-tree, git show-ref, git rev-list, git for-each-ref. It does not interact with the operating system or file system directly. Instead, the application invokes Git commands using the Java API provided by Bitbucket

In addition to commits, the application also uses Bitbucket's pull request metadata when generating graphs and reports. This metadata includes information such as ID, state, participants, author, created date, updated date, and so forth.

Application logs

The application stores logs in the Bitbucket log directory in files named awesome-graphs*.log. These logs contain the following information:

  • Enabling and disabling the add-on events
  • Indexing details
  • Progress of database migration during app updates
  • Errors, including stack trace

Upon disabling or uninstalling the application, tables containing the app data remain in the database, and the application logs are stored as well. If the app is reinstalled, it continues to use the previously saved data.

Permissions

CategoryFunctionality accessAnonymous userAny authenticated userRepository/Project administratorBitbucket administrator

UI

Graphs and reports for projects and repositories according to the access level *

*At the project scope, graphs and reports only display information for repositories a user has access to

(error)(tick)(tick)(tick)

File Сontributors, if a user has access to the repository

(error)(tick)(tick)(tick)

People page *

*People page displays information about all users, even for repositories potentially inaccessible to a user: this ensures consistency so that users with different permission levels (such as admin and regular users with limited repository access) can see the same graphs for contributors

(error)(tick)(tick)(tick)

Contributions for any Bitbucket user *

*The graph contains the data of all user activities, however, the Activity Stream only shows activities for repositories accessible to the viewer

(error)(tick)(tick)(tick)

Settings

(error)(error)
(tick)

within their administrative scope

(tick)

Managing Emails *

*via App Settings

(error)

(tick)

own user profile settings page only

(tick)

own user profile settings page only

(tick) 


REST API

Data Export *

*Only data for repositories accessible to the user performing the export is exported

(error) (tick) (tick) (tick) 
(error)(error)(error)(tick) 

Adding/removing email aliases for other user accounts *

*Admin can manage System Admin's aliases

(error)(error)(error)(tick) 
Other 

CSV export *

*Only data for repositories accessible to the user performing the export is exported

(error)(tick) (tick) (tick) 

Customer support

Client data

When clients contact our customer support regarding technical cases, information such as app screenshots, query execution results, and support.zip files may be included. Clients provide this information:

Access to this information is restricted to support service specialists. Other Stiltsoft employees do not have access to this information. If a support specialist needs to download this information to their workstation for processing, they delete this information from the workstation immediately after closing the ticket.

Premium support

We use Paddle to handle billing and payments directly. We do not store customers' payment data ourselves — all data is stored in Paddle. Paddle is SOC 2 and GDPR compliant. The payment provider makes available the following information for us: the payer's zip (postal) code, country, card network type (Visa, MasterCard, American Express, etc.), last four digits of the card, and expiration date.

Personal data provided during the purchase of a Premium Support subscription is stored and processed in accordance with the Stiltsoft Europe Privacy Policy.

All terms of the premium support subscription can be found in the Stiltsoft Premium Support Terms.