5 ways to automate security testing in DevSecOps
Read up on five areas of DevSecOps that benefit from security testing automation, such as code quality checking, web application scanning and vulnerability scanning.
The key to both DevOps and DevSecOps is automation. It ensures build and release processes are repeatable, which is important when release velocity is too high for manual steps to occur between release phases or at set times.
Automation ensures required steps are completed each time code is pushed and removes human memory from the equation so key tasks, such as regression testing, get done. Automation also helps strengthen security by serving as policy enforcement to prevent direct developer access to production and thereby serving as the enforcement point for segregation of duties.
For many security practitioners, particularly those who do not come from an application security or software development background, it can be difficult to identify opportunities about where and how to automate security testing in a development pipeline.
Here are five areas where teams can add automated security checks into development pipelines.
1. Code quality (SAST)
Perhaps the control that springs to mind first when people think about software security is code quality -- i.e., static application security testing (SAST). Those familiar with the Unix tool Lint, used to find errors in C code, understand the concept of static code scanning.
Static analysis tools evaluate source code or, more rarely, object code for security issues. In the context of a DevOps toolchain, this can be automated in one of a few different places:
- It can operate when a developer commits code, i.e., when scanning code and providing data about whether there are high-severity issues.
- It can occur prior to a build.
- It can be used when using a tool that can validate object code rather than source in post-build.
One strategy can be to establish a baseline metric -- an acceptable error rate -- above which user intervention is required. Base this on number of issues, severity of issues or both. Above this threshold, require a developer to take action to remediate the code before it can be promoted. Another option, depending on release cadence and tuning of SAST for false positives, is to flag the issue for further review downstream but not actively gate the code push.
2. Web application scanning (DAST)
Automation can be added to the dynamic testing of applications after being built but before they are released to production.
Dynamic application security testing (DAST) tools operate by investigating an application from the outside in. This involves looking at the surface area of an application, interacting with it and observing what transpires. Within a DevOps toolchain, a useful place to include automated use is post-build during automated quality assurance. As a way to get up and running quickly, explore using the open source application scanner Zed Attack Proxy in daemon mode -- i.e., command-line interface only -- automatically triggered to run in parallel with other testing activities. Test web UI elements with this approach or REST APIs, for example, by incorporating parameter fuzzing.
3. Container scanning/vulnerable dependency analysis
In most shops nowadays, new application development is dependent on application containers, such as Docker or Rkt. Containers are advantageous because they package together an application or component and the underlying libraries, middleware, resources and other dependencies required.
This is a useful feature of containers, but one of the potential drawbacks is that, sometimes, those underlying components have known vulnerabilities. Since the container has the dependencies grouped together in a way that requires less work from an operations point of view, the temptation can be to forget about those vulnerabilities or to not realize they exist.
Automated tools that scan containers, such as open source Clair or Anchore Engine tools, look at dependencies within a container to help alleviate this issue by finding and reporting vulnerable supporting components. To automate, these tools can be run on containers at any point after they are created. Should major issues be discovered in dependencies, trigger manual review to remediate the vulnerable dependency, note the issue for future action or take any other action needed.
4. Software composition
There are many reasons for a company to create a software bill of materials (SBOM) -- both for the company itself and its customers. The hard part of producing an SBOM is the complexity associated with keeping the list of underlying dependencies current and accurate. Introducing a software composition analysis (SCA) tool into a toolchain is a useful way to help keep an SBOM updated.
An SCA tool can also help determine where best to add automation. For example, software that operates on object files or executable images would need to run post-build, whereas one that operates on source could happen in parallel with commit.
5. Automated vulnerability scanning
The tools listed above cover most software components but not all. Web UI systems and REST APIs are scannable by DAST, and containerized software goes through container scanning. But what about software that's neither?
For these, it can be helpful to incorporate vulnerability scanning. Teams deploying to a VM in the cloud or deploying a customized OS installation will find a vulnerability scan can help them find and flag potential security issues. Automating vulnerability scanning pairs nicely with configuration management -- meaning, whenever the configuration of a deployed resource is changed (think infrastructure-as-code scripts here), running a vulnerability scanner afterward can provide value.
