Recommended customer security best practices

This page provides an overview of security practices and recommendations for mabl customer's use of the mabl system.

Mabl Link

The mabl Link agent creates a secure tunnel between customer networks hosting internal applications and tests running in the mabl cloud. Mabl secures this tunnel so that only traffic generated by containers and virtual machines running your tests is proxied over it. All traffic from tests using a given Link agent is proxied through the node(s) running that Link agent. Given this, we recommend you follow the Principle of Least Privilege for the machines running the Link agent and give them access only to necessary applications and services.

Test data and artifacts

Test artifacts and data are stored securely in mabl using workspace specific encryption keys and protected by robust information security policies and procedures. However, mabl is NOT currently HIPAA or PCI certified. We recommend all customers use test accounts and data, even when testing in production. This is especially important if your application collects any sensitive patient or credit card data.

Credentials and other secrets

To execute end to end tests in the cloud, it is typically necessary to store credentials and other sensitive secrets in mabl. To provide additional security, mabl encrypts credentials, environment variables, and custom HTTP headers with a customer-specific encryption key before writing them to our database. To facilitate local test replay, basic credentials, environment variables, and custom HTTP headers are currently available to any member of the workspace.

Our most secure option for credential storage is cloud credentials. Using cloud credentials ensures that the password cannot be retrieved once saved. However, cloud credentials are not available for use in the mabl Trainer or local test runs.

To minimize the impact of any exposed credentials or secrets, mabl recommends the following best practices:

• When testing in environments that contain customer data, such as production, use test accounts and save the credentials as cloud credentials.
• If your system supports it, only use secrets shared with mabl for running tests in mabl. For example, if you can generate API keys used to access your system, give mabl its own API keys that are not used by anyone else or any other processes.
• For users with a large number of users and applications, we recommend using separate workspaces to isolate access to credentials and secrets. At the current time, mabl does not have support for restricting access to specific credentials by individual users or roles

📘

Access to credentials and API keys

Credentials can be created, viewed and modified by editors and owners of a workspace. API keys can only be created, viewed, and modified by workspace owners.