Automating Security with DevOps: It can work

DevOps and Security have often been considered mutually exclusive. Both are imperative to developing high-quality applications, but continue to be seen as entirely separate processes.

Tools that combine DevOps and Security tend to only integrate static security code analysis, and do so within the early stages of Continuous Integration. These scans are performed simultaneously, running unit tests whose results are used as quality gates that can also act as step-by-step guides to improving technical debt.

However, the tools available are considerably limited. In order to execute automatically, the static security tools test a portion of an application, and rarely on a deployed instance.

A common myth is that more in-depth scans and penetration tests to validate a running application must be performed manually or through a labor intensive GUI interface. These steps still need skilled resource dedication and in-depth manual testing, but much of the initial process can be automated. A great tool that can be integrated into the DevOps pipeline to perform the initial system scans is OpenVAS. It can be executed automatically and save time and resources.

Why OpenVAS?

OpenVAS (Open Vulnerability Assessment System) is a free security tool. There are many other products that provide similar services (Nessus comes first to my mind) but it is hard to argue with a $0 price tag.

OpenVAS contains an extensive volume of checks run against both the server and a deployed application. The rules applied do tend to focus more on the services running on a server than a complicated business logic vulnerability within the application. Through its integrated components, OpenVAS runs application security checks—testing for legacy and outdated running services, excessive open ports, XSS, SQL Injection, Buffer Overflows, and similar security issues. It directly executes Network Vulnerability Tests based on MITRE’s Common Vulnerabilities and Exposures list to generate results with a high degree of confidence. In the event that a High security vulnerability is discovered, it is unlikely to be a false positive.

Usage: Not Intuitive, Not Impossible

My biggest obstacle implementing OpenVAS within DevOps has been its usage. OpenVAS has its own unique identifiers for variables in the command line. When automating with a tool like Jenkins, this produces a complicated intermediate step. For example, scripts must be executed to identify and extract the identification tags associated with the type of scan to be performed, the desired report type, the task to run, and the end report ID.

The direct OpenVAS command line queries needed to go create a task, run the scan, and generate results are as follows:

omp -u admin -w admin_password -g > ScanType.log

omp –u admin –w admin_password –xml= ’$TARGET_NAME$TARGET_IP_ADDRESS‘  > TargetID.log

omp -u admin -w admin_password –xml= ’$SCAN_NAME$SCAN_TYPE scan on Target Server $TARGET_NAME at IP address $TARGET_IP_ADDRESS’     > task_id.log

omp –u admin –w admin –xml=’’

omp –u admin –w admin_password -iX ‘’   >  report_id.log

omp –u admin –w admin -iX ‘’   > report_formats.log

Note that the commands to extract the desired identification values were not included in the above specific OpenVAS commands.

Value is in the Results

For demonstration purposes, the OpenVAS tool was run against a VM of the vulnerable Metaspoitable test system. Many services were found to have exploitable security issues with a large number of excessive ports open and in use.

Remember: due to the library being used and the way in which OpenVAS verifies the vulnerabilities, any findings should be considered to be valid and exploitable.

Only a portion of the issues were included here as the tool goes through every finding, from High to Informational, and includes their recommended resolution. Using the information provided, a developer or system’s administrator has a list of actionable tasks to remedy the open security vulnerabilities or reduce their attack surface. Some examples of the output from the High issues:

Final Thoughts

This security scanning tool is not a replacement for a well-developed security testing process. However, it does act as a strong supplement to identifying and resolving issues. This tool was scripted to execute automatically and run against a test environment. A manual process is still required to interpret the results and confirm their validity and applicability.

By combining OpenVAS with other tools such as HP Fortify and OWASP ZAP into DevOps, you can obtain a strong understanding of the application, how it functions, and the system hosting it. Then, when a human analyzes the system, they can skip the low-level tests and focus their attention on more complex problems.