Security FAQ

LambdaTest is a firm believer in secure experience and multifaceted security protocols, to ensure that every aspect including architecture, engineering, testing, and deployment, follows and complies with industry leading standards of security. As first line of defense, LambdaTest application is protected by AWS’s firewalls which are tasked with countering regular DDoS attacks and malicious network intrusions. The next line of defense is LambdaTest’s own application firewall protocols which are tasked with protecting the application against spam, ill-intent users, and malicious IP. We have also implemented secure user access policies for accessing LambdaTest platform and only users with valid user credentials can access the application. We have also implemented role based access to the application, each role having different access levels.

Whenever a user initiates a test at LambdaTest platform, they are allotted a thoroughly sanitized virtual machine. And as soon as a session ends, all data including cookies, registry, caches, and running processes are deleted and all browser settings are reset to default values. Each virtual machine has to pass a series of automated tests before it is used again. Any machine that fails a test gets redacted from the pool for auditing and manual cleaning. At the time of test only the user has access to machine and not even LambdaTest has access to the user’s running test session. All machines have strict security protocols that prohibit any user from installing any external software in the machines.

In our application we have implemented HTTPS by default, and use VNC protocols for secure data transfer. This data is also encrypted to ensure that data is not compromised in-transit.

All our hosting centers are chosen based on their record of established security policies and excellent history. Our selection process is rigorous and we partner with only the best providers across globe that have been certified by major compliance regulators.

All data saved in our application like login credentials, secure access keys, usage logs, test history, and billing details, are stored in an encrypted format.

We have implemented strict 24×7 security protections at our on-premise development centers. Only authorized individuals have access to building and LambdaTest office premises. Our application data is hosted on industry leading hosts like Amazon Web Services, who have been thoroughly tested by multiple third party auditors for security. You can also read more about Amazon Web Service’s Security Here.

All our data is hosted and stored in Amazon Web Services infrastructure, which has multi-level disaster recovery features. We implement all AWS guidelines and protocols on Disaster Management as advised in this document by here.
Yes. All our employees sign confidentiality agreements which extends to user agreements between LambdaTest and Clients. Also, we have strict user role based access to all our customer data therefore, only most important employees have access to only relevant data.
We do not have any information or system security certificate at this moment. We have however, applied for Service Organisation Control (SOC) 2 Report compliance certification from US agencies.
Our application is micros-services based product. Database is restricted from public access. It is only accessible to the application though encrypted authentication based APIs and that also over a secure private network.
We here at LambdaTest follow Agile development methodologies with dedicated teams for automated deployment and testing. We use Jenkins as our preferred Continuous integration platform and use Sonar Cube for automated code quality control. We ensure maximum possible code coverage in our automated tests and each release is passed only before it pass all test scenarios.
We periodically tests our applications for vulnerability both through automated and manual means. We perform regular audits of databases to check for irregularities, and our ELK stack implementation gives real-time insights on any possible attacks.
Access to production system is strictly controlled though role based authentication access. No LambdaTest employee has complete access to all data, each having their relevant role based access to data. Each employee has his/her own email based authentication passwords for accessing applications and after termination we revoke their complete access to the application. In addition we maintain automated logs of each database ingress and regularly monitor the logs to find discrepancies.
All user access is password protected. In addition user sign-ups are verified through a two-step verification workflow.

At LambdaTest, we maintain a variety of logs such as syslog (system logs), auth (authentication) logs, firewall logs, web server logs, application server logs, database server logs, netflows etc. We have an inhouse implementation of ELK stack for logging and business intelligence. Our implementation gathers and consolidates data from all micro-applications into a secure private network. The data is used for product analysis by product team through our custom log processing and BI system. The BI system in turn is secured thorugh a IP based access policy. In addition only authorized LambdaTest employees has access to relevant pieces of data based on their role. All log data is saved in encrypted format private storage volumes that is encrypted usign DM-Crypt disk encryption system
We follow SemVer versioning standards and publish hot-fixes and patches as it is required.
Yes. We have separate Production, Dev, and Test Environments. Each Environment is hosted in separate instances and is secured behind a private network.
All environments are hosted on independent AWS instances. Only Live environment has critical user data. Rest of the environments have dummy or simulated data that covers all use cases.
We perform periodic system vulnerability scans, both automated and manual, using a OpenVAS based solution. We check for all major vulnerabilities and security risks as enlisted in open source databases like https://nvd.nist.gov/.
Our application is hosted on Amazon Web Services and we follow all DDoS mitigation guidelines detailed by AWS in this documentation paper . We use services such as Amazon Route 53, Amazon CloudFront, Elastic Load Balancing, and AWS WAF to control and absorb traffic, and deflect unwanted requests. We also have a Cisco ASA firewall in place as added security measure. In additon to all this we have put into place custom firewall and security measures based on Fail2Ban intrusion protection framework to prevent brute-force attacks.
We have implemented advanced analytics using Kibana, Kubernetics, and AWS data tools. We monitor all our networks constantly for suspicious activity. We also use Elastic.co’s Beats product for shipping data. Beats comes with in-built monitoring and data visualization tools that help in real-time monitoring of application.
Yes. All user credentials are stored in a manner compliant with all NIST guidelines as defined here.
All user data is stored as encrypted data in secure AWS storage hosted databases. We use AWS S3 for data storage and have enabled advanced AES256 encryption standards for Data at Rest. For Data in transit we use VNC and WSS security and encryption protocols.
All data such as user credentials are secured in encrypted format and no LambdaTest employee can access it, including administrators. User data such as company details, user contact details, test logs, etc. can be access by only relevant developers. We have strict user role based data access and only relevant developers have access to parts of user data. This security access is audited every month based on development and testing sprint plans.
We use AWS services like AWS S3 to store and take backups of our data. All data stored on AWS instances are stored using advanced AES256 encryption standards. Any data that is not critically required gets deleted through standard DELETE requests on S3 buckets. However we have implemented versioning and rollback steps to prevent accidental deletion of data. Therefore, even delete requests do not immediately delete all data. For that we have implemented provisions to scrub all data including the historical backup data on client requests.
Our application is hosted entirely on third party hosting providers like AWS, Hetzner, etc. All our hosting partners have very high security protocols. For example checkout AWS security protocols here, or Hetzner Security protocols here
We, here, at LambdaTest follow a 6 step incident reponse process. The various stages of the response proces are prepration, identification, containment, eradication, recovery, and learning. We use industry leading practices for each step and test our response workflow once a month.
In case of an identified breach, all related users are notified of the breach immediately so that they can take necessary measures to prevent further loss. We share this information with our signup users through our email channels, and also notify users through social media platforms like LinkedIn, Facebook, and Twitter.
None. Only web requests initiated on LambdaTest platform are transported to your localsystem via SSH tunnel created by our tunnel binary. The data at rest and data at transit are both encrypted. Only web browsing data generated by a webbrowser selected on LambdaTest platform can send data to your system. As such your system is not exposed to public. In addition, every tunnel created using Lambda Tunnel binary is isolated to users of the same account. All Information of the remote tunnel is secured by accesstoken and we employ latest technology in encrypted tokens. This information is only provided to the browser fired the user. With that said, LambdaTest recommends using test data instead of production data as best practice.