Here are five areas where teams can add automated security checks into development pipelines.
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:
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.
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.
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.
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.
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
