Test Automation, Security, and other vegetables

Automation, Security, and other vegetables

What is commonly overlooked when focusing on Quality?

In this blog post, I want to delve into an aspect commonly overlooked in the context of Test Automation, and that’s the Security aspect. 

As test automation developers, we often overlook the basic fact that we are working on a software project. Just like any other software project, considering security in our test automation practices adds a vital layer of protection to our work environment and helps ensure that our work which was initially meant to save time and help quality efforts, will not provide an easy and accessible breach point to our application. 

So, on this note, let’s dive into why security should be an integral part of our automation efforts and explore some strategies to ensure our project is as effective as it is secure. 

Analyze the attack surface - Before we can effectively secure our test automation infrastructure, it's crucial to identify and analyze potential attack vectors. This involves examining the various entry points and pathways that could be exploited by malicious actors. In simple words, you need to map out every repo, every resource, every instance, every VM, and every network access your test automation infrastructure uses to proceed to analyze which threats it can introduce. Write them down and include which security measures you already have in place and what action items are needed going forward. If you are pulling dependencies from the internet, consider using a binary management system that would store your dependencies and potentially some products allow easy integration with scanning tools to alert on any license, CVE, or any other vulnerability threats found in your repository.

Eliminate low-hanging threats - Let’s start by understanding what we have and what can go wrong. Once you know what you have you can start eliminating the possible threats. 

Go over your automation repository and look for any clear text passwords, API tokens, Keys, credentials, High access certificates, and any other clear text vulnerabilities that it might contain. 

As a general rule, all secrets need to be stored in some kind of secret manager. It can be Vault, Keeper, AWS Secret Manager, or any other solution that can be securely incorporated into your workflow. Make sure you are not printing out any secrets anywhere along the way. It can be in your Jenkins console, standard output, PII data in logs, etc. Make sure that every end station running automation does not have any secrets stored decrypted or unprotected on it. 

Rotate secrets - In general, it is a very good practice to systematically and periodically rotate any secrets or credentials you might be using in your test code. If you are using static or highly privileged users then make sure that you have an expiration policy for their credentials and that you have good analytics and sensors that can monitor any suspicious or abnormal activity related to these users. 

Allow connection and access only to where it is necessary - Though it might sound like a hassle, it is important to understand what your automation code/running platform can access in terms of network connectivity and restrict it to the minimal necessary access policy to avoid malicious actors from accessing data by bypassing the company’s security measures from any workstation or run platform. Make sure that if needed, any calls made by your test automation code pass through a corporate Firewall or less recommended - Proxies. 

Protect, scan, and monitor remote run platforms - This is kind of a big topic but when it comes to remote run platforms utilized for test automation, ensuring their security is essential. Here are some actionable items to implement:

• Controlled Access: Restrict access to remote run platforms only to authorized users or systems. Implement strong authentication mechanisms such as multi-factor authentication (MFA) to prevent unauthorized access.

• Proxy Restrictions: As I mentioned in the previous section, configure the remote run platforms to route all network traffic through designated proxies or corporate Firewalls. This helps enforce security policies, inspect traffic for malicious activity, and prevent unauthorized data exfiltration.

• Privilege Management: Ensure that users on remote-run platforms have only the necessary privileges required for their tasks. Avoid granting high-level shell privileges unnecessarily, as this could increase the risk of unauthorized access and system compromise.

• Monitoring and Logging: Implement strong monitoring and logging mechanisms to track user activity, system events, and network traffic on remote run platforms. Regularly review logs for suspicious behavior and security incidents, and take appropriate action as needed. I also recommend setting up alerts for any events or findings that can be sent directly to your corporate Slack or Email. 

• Regular Security Scans: Conduct regular security scans and vulnerability assessments on remote run platforms to identify and remediate potential security weaknesses. This includes scanning for outdated software, misconfigurations, and known vulnerabilities. Different tools out there can help you achieve this like Checkmarx, WIZ, etc. Make sure you have comprehensive Alerting and that you handle any HIGH severity findings in a timely fashion. 

• Enforce Best Practices: Enforce security best practices such as disabling SSH access via sudo, restricting SSH access to specific users or groups, and regularly updating software and system configurations to mitigate emerging threats. That includes OS patching as well.

Don't make automation a liability. And that goes both ways.

In this last section, I want to make one thing very clear. Automation is meant to save time and money while helping to provide Quality Assurance. While it is important to be as secure as possible if you feel like you have to pass an obstacle course just to run your regular coverage suites, if you feel like you are constantly investing time to troubleshoot, recalibrate, and handle blockages Rate limits and other security bottlenecks than you need to stop and re-assess. Any measure in place has to provide adequate protection while keeping in mind that at the end of the day, Automation needs to have a positive ROI. 

I hope you found this post useful, be safe and stay secure.