What Is Automated Security Testing?
Security testing processes and tools help identify security weaknesses and vulnerabilities in applications and software. The goal is to find issues that can potentially allow threat actors to obtain unauthorized access or otherwise attack the tested system.
Automation helps minimize the amount of manual work spent on repetitive tasks, increase testing speed, and extend testing from a periodic process to a continuous one that provides consistent results.
Automated security testing is more cost-effective than manual testing, helping run various tests to ensure the software and systems remain secure and free from critical vulnerabilities throughout the entire software development lifecycle (SDLC).
Automated security testing is especially useful for DevOps and DevSecOps teams looking to integrate security testing into the SDLC without reducing productivity. These tools can run various tests, including penetration testing, source code analysis, security code review, and vulnerability scanning.
I’ll review three tools that are commonly used for security testing in a DevSecOps envirnoment – SCA, SAST, and DAST.
Automated Security Testing with SCA
Software composition analysis (SCA) tools help manage open source software components. SCA tools quickly identify, track, and analyze open source components in a project, including all related components, supporting libraries, and direct and indirect dependencies.
SCA tools can identify software licenses, security vulnerabilities, potential exploits, and deprecated dependencies. At the end of the scanning process, the tool generates a bill of materials (BOM) that includes a complete inventory of the project’s software assets.
Here are notable benefits of SCA tools:
- Build and deliver high-quality code using a proactive risk management approach.
- Identify security vulnerabilities and risks early in the SDLC and select the most secure components upfront.
- Minimize the number of security assessments by testing early on when first introducing third-party components and libraries into the application.
How SAST works
Here is a breakdown of the SCA process:
- Scanning—SCA tools scan a codebase to create an inventory software bill of materials (SBOM) that includes all detected open source components and dependencies.
- Informing—the tool records all identified components, specifying license information, the location of detection, and the component’s version. The accuracy and extent of the information generated depend on the open source information database the tool uses to analyze the scan results.
- Detecting—identify open source security vulnerabilities, such as those listed in the common vulnerabilities and exposures (CVE) and common weakness enumeration (CWE) glossaries.
- Alerting—the tool pushes alerts to notify the relevant stakeholders of detected vulnerabilities and potential license conflicts.
- Preventing—advanced SCA tools compare open source components against predefined policies and automatically block an affected project from promotion into production or notify stakeholders to remediate rapidly.
- Integrating—SCA tools can integrate with CI/CD pipelines to automate scans of projects and new project versions with each commit.
Automated Security Testing with SAST
Static application security testing (SAST), also called static code analysis, is a process that identifies vulnerabilities by scanning applications. It analyzes patterns in byte code, source code, and binaries, as well as data and control flows in an application. SAST helps identify common vulnerabilities without running applications.
SAST creates a model of the application’s data flows and code and runs specified rules against this model to detect registered vulnerabilities. Organizations that create apps using different platforms, languages, and frameworks should implement these steps to ensure effective SAST:
- Select the right SAST solution—the tool must be compatible with the application’s programming language and framework.
- Deploy the tool—the organization must handle licensing requirements, set up access controls, and provision resources.
- Customize the solution—the configurations should match business needs and minimize false positives.
- Prioritize and test applications—high-risk apps should undergo scans first.
- Analyze the results—this involves eliminating false positives after completing the tests and allowing the deployment team to remediate issues.
Proper training and oversight are essential to ensure that development teams use the SAST solution correctly. SAST tests should be an integral part of the development and deployment pipeline.
Automating Security Testing with DAST
Dynamic application security testing (DAST), also called dynamic code analysis, is a process that identifies vulnerabilities in running applications. DAST scans applications in compile-time and runtime to find vulnerabilities visible only in a running application.
Teams implement DAST when an application advances past earlier life stages and enters into runtime or production. DAST tools typically test only exposed HTML and HTTP interfaces of web-enabled apps. However, some tools can test non-web protocols and data malformation, such as session initiation protocols (SIP) and remote procedure calls (RPC).
How DAST works
DAST is a black box technique performed externally to the application without any view into its architecture or source code. It involves using similar techniques to those a malicious actor would when attacking the tested application. For example, a DAST tool can use injection techniques like malware injection to detect SQL injection (SQLi) and cross-site scripting (XSS) vulnerabilities.
DAST tools continuously scan web applications during and after development, crawling through the application before scanning it. Crawling the application enables the DAST tool to find all exposed inputs on pages in the tested application so it can test each one.
Fully automated DAST tools can test the application after it is executed to identify and help resolve risks before they escalate to attacks. Once the tool discovers a vulnerability, it sends an automated alert to the team to remediate it.
When to use DAST
DAST can help test early and often in the SDLC. DevOps teams often use DAST to identify and fix issues, usually in conjunction with other testing techniques, as part of a comprehensive web security testing approach.
DAST provides timely insight into how web applications behave in production. Additional forms of security testing techniques are required to gain more comprehensive visibility. DAST is typically combined with penetration testing (to get a real-world demonstration of how a malicious intruder might breach a web application) and static application security testing (SAST) (to find vulnerabilities in the source code earlier in the SDLC).
Automated Security Testing with Container Scanning
Most modern application development involves containers like Rkt or Docker. Containerized applications are easier to build because teams can package components with any underlying resources, middleware, libraries, or other dependencies.
While this ability is useful, it is also a potential drawback of containers because the packaged components and dependencies can include security vulnerabilities. Containers group dependencies together so that operations teams can manage them with less effort, but teams can easily forget or overlook the vulnerabilities.
Automated container scanning tools look for dependencies in containers to help reduce the vulnerability management effort—they find and report components with vulnerabilities. These scanners can work on containers automatically and trigger a manual response when they detect an issue in a dependency. The security team can review and remediate dependencies and log issues for future reference.
Automated Vulnerability Scanning
DAST, SAST, and SCA tools can protect most application components, but they don’t cover all possible vulnerabilities. DAST can scan REST APIs and web UI systems, while container scanners can check containerized software, but some software doesn’t fit into either category.
Vulnerability scanning can be useful for other types of software. The development team can use vulnerability scans to find security issues when deploying customized operating systems or virtual machines (VMs) to the cloud.
Automating these scans makes it easier to manage configurations—for example, by running a vulnerability scanner after each change to a deployed resource’s configuration.
How Frequent Should Scanning Be?
Thousands of new vulnerabilities are discovered yearly, but attackers only need to exploit one vulnerability to breach the network. Unfortunately, vulnerability scans only provide information about the known risks at the time of each scan. It is important to maintain up-to-date vulnerability data, but continuous scanning can drain resources, generate false positives, and slow down the system.
Attacks can exploit new threats in between scans before the organization is aware of them. Thus, both external and internal vulnerability scans should be routine. Automated scans can run on a regular schedule (e.g., monthly). Several regulations require organizations in certain industries to perform more frequent vulnerability scans.
Conclusion
In this article, I explained how to use three categories of security tools to implement a robust security testing process:
- SCA – lets you automatically test if components in your software project and their dependencies have security weaknesses.
- SAST – lets you automatically test source code at every stage of the development lifecycle, and provide fast feedback to developers about security or code quality issues.
- DAST – lets you automatically test applications running in test, staging, or production environments.
I hope this will be helpful as you transition to a full DevSecOps work process and level up your application security.
