5 ways to automate security testing in DevSecOps

The key to DevOps and DevSecOps is automation. It ensures that build and release processes are repeatable, which is important when the release speed is too fast to take manual steps between release phases or at set times.

Automation ensures the necessary steps are taken every time code is transmitted and removes human memory from the equation so that important tasks like regression testing can be done. Automation also helps increase security by acting as a policy enforcement to prevent direct developer access to production, thus acting as an enforcement point for segregation of duties.

For many security professionals, especially those with no background in application security or software development, it can be difficult to see ways of where and how to automate security testing in a development pipeline.

Here are five areas where teams can insert automated security reviews into development pipelines.

1. Code quality (SAST)

When you think of software security, you might first think of code quality, that is, Static Application Security Testing (SAST). Those familiar with the Unix tool, Lint, used to find bugs in C code, know the concept of static code scanning.

Static analysis tools evaluate source code or, less often, object code for security aspects. In the context of a DevOps toolchain, this can be automated in one of a few different places:

  • It can work when a developer is defining code, that is, when scanning code and providing data about whether there are serious problems.
  • It can occur before a build.
  • It can be used when using a tool that can validate object code instead of the source code in the post-build.

One strategy can be to establish a base metric – an acceptable error rate – above which user intervention is required. Base this on the number of problems, the severity of the problems, or both. Above this threshold, a developer must take steps to correct the code before it can be promoted. Another option, depending on the release rate and the coordination of SAST with false positives, is to mark the problem for further review, but not to actively block the code push.

2. Web Application Scanning (DAST)

Automation can be added to dynamic testing of applications after they are built but before they are released into production.

Dynamic application security testing (DAST) tools work by examining an application from the outside in. This includes looking at the surface of an application, interacting with it and watching what happens. Within a DevOps toolchain, the post-build during automated quality assurance is a useful place to include automated usage. To get up and running quickly, consider using the open source application scanner Zed Attack Proxy in daemon mode – that is, only through the command line interface – which is automatically triggered to run in parallel with other testing activities. Test web UI elements with this approach or REST APIs, for example by integrating parameter fuzzing.

3. Container scanning / analysis of vulnerable dependencies

In most shops these days, the development of new applications is dependent on application containers such as Docker or Rkt. Containers are beneficial because they package together an application or component and the underlying libraries, middleware, resources, and other required dependencies.

This is a useful feature of containers, but one of the potential drawbacks is that these underlying components sometimes have known vulnerabilities. Since the dependencies are grouped in the container in such a way that less work is required from an operational point of view, there is a temptation to forget or not to recognize these weak points.

Automated tools that scan containers, such as open source tools from Clair or Anchore Engine, examine dependencies within a container to fix this problem by finding and reporting any susceptible supporting components. For automation, these tools can be run on containers at any time after creation. If serious problems are discovered in dependencies, trigger a manual review to resolve the vulnerable dependency, record the problem for future action, or take other necessary action.

4. Software composition

There are many reasons for a company to create a software bill of materials (SBOM) – both for the company and for its customers. The difficult part in creating an SBOM is the complexity involved in keeping the list of underlying dependencies current and accurate. Introducing a software composition analysis tool (SCA) into a toolchain is a useful way to keep an SBOM up to date.

An SCA tool can also help determine where best to add automation. For example, software that works with object files or executable images would have to run after the build, while software that works with source code could run in parallel with the commit.

5. Automated vulnerability scanning

The tools listed above cover most of the software components, but not all. Web UI systems and REST APIs can be scanned by DAST, and containerized software goes through container scans. But what about software that is neither?

For these, it can be helpful to integrate vulnerability scans. Teams deploying a VM in the cloud or deploying a custom operating system installation will find that a vulnerability scan can help them find and report potential security issues. The automation of vulnerability scans can be combined well with configuration management – that is, if the configuration of a provided resource is changed (think of infrastructure-as-code scripts here), the subsequent execution of a vulnerability scanner can be useful .

Comments are closed.