Testing a mobile app is more than just testing its business logic and UI. Increasingly, security testing is becoming a cornerstone of developing modern applications. 

In 2021, there was a 650% increase in software supply chain attacks. The same report states that many of the most popular open-source libraries contain at least one know security vulnerability. There are multiple other reports which indicate that cyber crime and attack attempts are on the rise. Luckily, more and more companies are taking security risks seriously and incoroporating it into their test process, in part due to the increased number of mediatized data breaches, but also thanks to the DevSecOps movement. 

DevOps is the practice of having development teams be responsible for the full lifecycle of their software—both building it and keeping it running. Adding security to the mix means that they're now also responsible for securing their applications. Security is no longer the sole responsibility of dedicated testers or security specialists. In order to successfully combine these three roles, teams are looking toward automation. Automated security testing covers the "sec" in DevSecOps, and it's what we'll be discussing in this article.

Manual vs. Automated Security Testing

Manual security testing is when security teams manually assess the security of a piece of software. For this, they use their expertise and their knowledge of the system. It's a lengthy process, but it can be a valuable addition to automated security testing. 

Automated security testing involves using tools that automatically scan the software for known security vulnerabilities. The tools can check any number of aspects, like software libraries, source code, or API endpoints. Automated security testing is often faster to run and can be incorporated more easily in the daily workflow of a team. 

Because it's so convenient and efficient, automated security testing should be implemented by all organizations that take their product seriously. But manual testing can still add value, and depending on the context, you'll use one or the other. An experienced security expert can be creative and find new ways of breaking the system under test. However, repetitive or easy security tests will unnecessarily take up resources and should be automated.

Benefits of Automated Security Testing

We already briefly touched on some benefits of automating security testing: it's more convenient and more efficient. It'll also help produce a higher quality product. Let's dive into the benefits in more detail below. 

Repeatable Security Checks

Like other types of automated tests, security checks must be run regularly. This ensures that a type of vulnerability that previously wasn't a problem doesn't get introduced into the system without the team knowing. Consequently, the product benefits from remaining secure.

Early Security Assessment

Automating your security tests means you can run them as early as possible in the software development lifecycle (i.e., shift left). This can help catch security issues before they go into production, which can have disastrous results. As such, it decreases stress and pressure on the team and saves time and money. 

Streamlined Threat Management

Managing the myriad of security threats that a team faces can be a daunting task. Security test automation tools can help by providing clear reports, which developers, security experts, and management can use to prioritize and assign tasks. This avoids wasting time and helps in fixing the vulnerabilities faster. 

Reduced Human Error

Manual security testing not only takes up quite some time, but it's also prone to human error. If a repeatable (and thus automatable) security test must be done manually, it's possible that the tester might make a mistake now and then. This can result in false positives (e.g., the tester found a vulnerability that isn't actually in the system) or false negatives (e.g., the tester didn't find an existing vulnerability). The first case is a waste of time, and the second is a security threat.

Clarification of Responsibility

Related to the streamlined threat management, automated security testing can make it clearer who is responsible for prioritizing and applying the security fixes. For example, a tool that analyzes source code or software libraries can present a report that developers can use to fix the issues at development time. The infrastructure team could use another tool to scan the servers, network, and cloud infrastructure.

Ease of Integration

A central aspect of DevOps is automation, so it only makes sense to also automate security testing. Scripting these tests makes it a lot easier to integrate it in the daily workflow of a team. Security checks can run automatically in the background and notify the team if any vulnerabilities are found. Or they can be part of the continuous integration process and fail the build if there are new security threats. This constant testing delivers a more secure and reliable product than manual tests would have done because manual tests are inevitably run less regularly.

Ease of Expansion

With the correct tools, new security checks are added easily and often without any effort for the team. SaaS products that scan source code and software libraries are constantly being updated by the vendor. Once the team has installed the tool, they have little maintenance to perform on the tool itself.

More Time for Priorities

With automated security tests, a software team has more time to focus on their priorities. Automation frees up their time to deliver business value in the form of new or improved features.

Ways to Automate DevSecOps Security Testing

IBM defines DevSecOps as a practice that "automatically bakes in security at every phase of the software development lifecycle, enabling development of secure software at the speed of Agile and DevOps." This means that we should take security seriously from the start of the development process, and that we automated it as much as possible. 

In DevSecOps, the team thinks about security in the analysis stage (will this feature be secure and/or how should we secure it?), the development stage (by scanning source code and software dependencies), and after deploying to QA and production (by running security tools against these environments). Here are a few ways to automate security testing.

Code Quality and Security Scans with SAST

Static Application Security Testing (SAST) tools are white box testing tools that scan an application's source code for known security issues. These code analysis tools recognize source code patterns that possibly pose security threats (for example, SQL injection or not encoding user input on the web). 

The results of these tests can be used early on in the software development lifecycle, and the team can run testing on every change in the code and immediately fix the issues.

Vulnerability Scanning

Applications depend on other systems like an operating system, a web server (e.g., IIS or NGINX), and a database or a user management system (e.g., Active Directory). These systems are also vulnerable to attack, so they must be configured correctly. That's why it's good to not only scan your own application, but also the systems your application uses. Running a vulnerability scanner and acting on the results are typically the responsibility of an infrastructure team. It's something they must run regularly, independent of any changes made to the company's applications.

Software Composition

Modern software development is practically impossible without using many software libraries that can be found online. Many of them are open source and free. Inevitably, these libraries are susceptible to security vulnerabilities. Using vulnerable software libraries will make your software vulnerable. Luckily, there are tools to automatically scan the libraries your software uses and flag any security issues. Many of them will even propose potential solutions, like telling you to which newer version of the library you need to upgrade to.

Container Scanning

More and more teams are using containers (e.g., Docker containers) to run their applications. This is another attack vector for hackers. Container scanning is the process of scanning containers and images for security issues. This is typically done during the development phase, before deploying the containers.

DAST Scanning on Existing Web Applications

A last type of tool that automates security testing is a Dynamic Application Security Testing (DAST) tool. These tools will scan a running application for security vulnerabilities. This type of test comes at a later stage (i.e., after development of a feature is finished and it has been deployed to an environment). Ideally, this is the QA environment so that any issues can be fixed before releasing to production.

Best Practices for Automated Security Scanning

Now that you know why automating security testing is so valuable, and the different approaches you can take, let's cover some best practices to adhere to.

Get the Team On Board

All of the above will make little sense if the team doesn't see the danger of security threats. Getting the team on board can be difficult, but having them understand the value and importance of security is crucial. 

Teams may be reluctant to add security to their already long list of tasks and responsibilities. But automating the process can help them see that the effort can be minimized. Also, any security issues found in production are usually more difficult to handle, require more work, and cause more stress than is the case at development time.

Test the Application in Parts or Units

Breaking the application into parts or units and checking for vulnerabilities within them can help identify failure paths and security loopholes even down to the most basic components of your application. Sometimes looking at the smaller pieces can reveal something that high-level integration testing might miss.

Use the Right Tool

There are many tools to choose from, but not all will fit your needs. Of course, the tool should handle the type of security test you want to run (SAST, DAST, container scanning, or any of the other types we covered). But it's also important that you can use it "in a DevOps way." You'll want to be able to run it easily on demand, but also integrate it into your automated build and deployment process, or have it run on a predefined schedule.

Test Against Malicious Acts

Not only should you perform automated security tests during development, you should also check your running applications. With DAST tools like OWASP ZAP (for web applications), you can attack your application in a controlled way and see if it withstands the attack.

What to Look for in Automated Security Testing Tools

Automated security testing ensures teams can incorporate it in their daily workflow, and that it's included from the earliest stages of the software development lifecycle. It frees up time and resources, makes responsibilities clear, and makes security threat management easier. But to do so, teams need one or more quality software tools to do the heavy lifting. 

A good security testing automation tool is complete, backed by a company that provides good support, maintained well (e.g., is kept up to date), and has a cost that the organization can handle. Of these requirements, teams should especially look at how the tool is kept up to date, because the security landscape is constantly changing, with new threats emerging everyday. 

Automation is central to DevSecOps, so not only should we automate our unit tests, integration tests, and UI tests, but we should also automate our security checks so that we can perform them regularly and still save time. The quality of our software will only benefit from more frequent security testing.

This post was written by Peter Morlion. Peter is a passionate programmer that helps people and companies improve the quality of their code, especially in legacy codebases. He firmly believes that industry best practices are invaluable when working towards this goal, and his specialties include TDD, DI, and SOLID principles.