What info is uploaded and kept on your server(s)?

For Drop Guard to operate, two components are required:

  1. The connection to a client website via the Drop Guard module
  2. The connection to a user's Git repository

In the first case, we do not store any information apart from a list of enabled modules and their versions. We keep no historical data whatsoever, so once you disable a module or delete a project - all the data is wiped immediately.

Speaking of Git connection - we do require read/write access to the repository to process updates. Before performing a module update a local cache is created in a temporary Docker container, which purpose is to handle this specific update only (run composer update commands, apply patches etc.). After the operation is finished (either with failure or success result), the container gets destroyed immediately.

If you don't want to grant Drop Guard access to your full codebase, you can create a separate repository with just the composer.lock and composer.json files, which is enough for Drop Guard to work in Composer mode. You can also grant Drop Guard access to a separate codebase containing only contributed modules and core.

Is the information encrypted in transit to your sever(s) and if so, what methods?

For encryption of the data coming from the client module, we use openssl extension from PHP and aes128 cipher method. Then we use the public key generated by Drop Guard server (you use it to connect to a client website) to generate the base64 encoded string, which is transferred via a secured protocol (in case the client website uses https). To see how it works, you can inspect the dropguard.module file.

What happens to my data if I delete my account?

If you delete the account your data is fully wiped from the database. In about a week or two the last remaining backup with the information about your account will be deleted as well from our servers.

Who in your company has access to the data? Is there role separation between developers and sysadmins?

Only two persons have full access and knowledge on how to access the data - the head of tech and the team lead. The rest of the team, including management, marketing, other developers in the company do not have access to any of the applications behind Drop Guard - the front end (interface visible to a user), and the backend (separate servers performing updates).

The logs and debugging data which may be visible for other developers are impersonated - they contain a project ID, type or operation and the status. If the problem requires direct communication with a user and checking his project status using a "master" Drop Guard account, it can be done only by a team lead, who is responsible for all further communications. A regular developer is not given permission to see the user project in full or "masquerade" as a regular user.

Regarding the role separation - the same people who work on the code work also on infrastructure. As we grow, this might change of course.

Can I export my data from the service?

At the moment - yes, but not via the UI. We can prepare a dump of your data from the database at any time if needed. But as we don't store any historical data, it will include your profile details and a list of projects together with their configuration.

Are on-premises options available if a client cannot use a cloud service?

We still do evaluate this option, looking for possible use cases and asking feedback from our existing and future users. As soon as we have a pool or users enough for us to justify the costs for building the on-premises version, we will do it right away. It will require a separate contract with us. The plan is to ship (and regularly update) the Docker containers needed to run the service and have a simple wrapper for basic management tasks. If you're interested, just let us know and let's talk!

Do you have monitoring in place to prevent and detect intrusion that would allow using the connection back to my Drupal servers as a vector?

We monitor the system 24/7 both manually and using automated tools, continuously analysing suspicious traffic and connected clients behaviour. In case something unusual is detected we disconnect a client from a system immediately, ban the IP and do a post-mortem review. We also keep our internal systems (open source libraries, modules, components used) always up to date and constantly monitor them for all possible security flaws.

In the very unlikely case of the attack targeting your servers from inside Drop Guard the only thing required to stop it will be to disable Drop Guard module.