Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Application Security

10:30 AM
Dave Meltzer
Dave Meltzer
Connect Directly
E-Mail vvv

Embedding Security into the DevOps Toolchain

Security teams need to let go of the traditional security stack, stop fighting DevOps teams, and instead jump in right beside them.

The adoption of DevOps continues to grow rapidly, and security teams are still trying to keep up. A natural starting point has been to focus on application security and securing the code itself. Although this is definitely an important piece of the puzzle, DevOps today has moved beyond just building application code into binaries into building complete system infrastructure in containers and virtual machines.

With this increased scope of DevOps comes all of the risks of the tens of thousands of known vulnerabilities and misconfiguration issues associated with the operating system, services, and system components included in the build. Just performing security assessments on the source code alone is not sufficient to identify these risks.

With the focus on speed and providing customers a constant stream of new features, DevOps teams typically haven't prioritized security first. Security is widely believed to be an inhibitor to agility, and using traditional security methods can be a bottleneck to DevOps agility. Security and IT operations teams understand that it's not sustainable to leave security out of the picture completely, but if security doesn't work at the speed of DevOps, it will continue to be pushed aside. This is why integrating security into the actual DevOps life cycle is key to managing risk effectively in the world of rapid development.

When looking to implement security at the speed of DevOps, one should understand what DevOps teams mean by the "CI/CD pipeline" and what that looks like. (CI refers to continuous integration, and CD refers to continuous delivery.)

Continuous integration is the concept that developers should be checking-in new code on a frequent basis (this could be several times a day). Code is checked in to a source code repository like GitHub, where an automatic build system, such as Jenkins, compiles the code and checks the new build to ensure the code didn't break anything.

The new build then continues onto the continuous delivery stage, where it is automatically deployed into testing environments for more involved end-to-end, load, performance, and integration tests. If everything passes, the new build is ready to be deployed to production. 

When deploying the new build, the DevOps team needs to define the right environment to run the applications and then ensure that all components are configured correctly. Tools such as Ansible, Chef, and Puppet are used for this.

Integrating Security into the Process
By understanding the CI/CD pipeline, security teams can see where it makes sense to put security controls in place and how they can match up to the existing DevOps workflow.

As mentioned, checking the source code being committed into the CI is a good first measure. However, many organizations leave it at that when they should go on to address the overall application infrastructure as it moves through the pipeline. It's not just code going through CI/CD process; operating systems, third-party components, middleware, and databases are being built and deployed along with that code.

The CI/CD process involves a DevOps toolchain, a set of automated tools facilitating the building, testing, environment configuration, and deployment of these systems. By integrating security into this toolchain, organizations can add effective quality gates that fit within the existing process to assess for vulnerabilities, configurations, and compliance with frameworks and/or organizational standards. It's important have quality gates and assessments at the different stages of building, testing, and deploying because many changes can happen between the code committing and the system deploying. It's often more costly and frustrating to reject applications at the end of the CI/CD versus having visibility and addressing issues along each stage.

The most effective way to do this is to integrate security tools with CI/CD build tools (e.g., Jenkins, TeamCity, and Bamboo) and CI/CD configuration tools (e.g., Puppet, Chef, Ansible, and Salt) to fully automate these assessments. The assessments can then either stop issues from continuing down the pipeline or at least provide visibility into the risk the business is accepting. To ensure vulnerabilities aren't slipping through the cracks, having the additional ability to dynamically test systems in a live sandbox would be a great benefit.

Just as important as preventing issues from going into production, organizations will want to monitor and maintain the integrity of their production environments. Several, perhaps hundreds, of production environments were configured specifically to make the DevOps-produced applications work, so once you've set it up correctly, you want to monitor for any configuration changes.

DevOps will continue to grow, so organizations must implement security solutions that work at the speed of DevOps. DevOps is the new world of developing, releasing, and updating applications for a growing number of enterprises; therefore, security teams need to let go of the traditional security stack, stop fighting DevOps teams, and instead jump in right beside them.

Related Content:

Learn from the industry's most knowledgeable CISOs and IT security experts in a setting that is conducive to interaction and conversation. Early-bird rate ends August 31. Click for more info

David Meltzer is Chief Technology Officer at Tripwire, a leading provider of security, compliance, and IT operations solutions for enterprises, industrial organizations, service providers, and government agencies (www.tripwire.com). He began building commercial security ... View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 7/14/2020
Omdia Research Launches Page on Dark Reading
Tim Wilson, Editor in Chief, Dark Reading 7/9/2020
Register for Dark Reading Newsletters
White Papers
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
The Threat from the Internetand What Your Organization Can Do About It
The Threat from the Internetand What Your Organization Can Do About It
This report describes some of the latest attacks and threats emanating from the Internet, as well as advice and tips on how your organization can mitigate those threats before they affect your business. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-07-16
IBM Sterling External Authentication Server 6.0.1, 6.0.0,, and 2.4.2 and IBM Sterling Secure Proxy 6.0.1, 6.0.0, 3.4.3, and 3.4.2 are vulnerable to an XML External Entity Injection (XXE) attack when processing XML data. A remote attacker could exploit this vulnerability to expose sensitive i...
PUBLISHED: 2020-07-16
IBM Team Concert (RTC) is vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session. IBM X-Force ID: 172887.
PUBLISHED: 2020-07-16
IBM Jazz Team Server based Applications are vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session. IBM X-Force ID: 173174.
PUBLISHED: 2020-07-16
MIT Lifelong Kindergarten Scratch scratch-vm before 0.2.0-prerelease.20200714185213 loads extension URLs from untrusted project.json files with certain _ characters, resulting in remote code execution because the URL's content is treated as a script and is executed as a worker. The responsible code ...
PUBLISHED: 2020-07-16
ConnectWise Automate through 2020.x has insufficient validation on certain authentication paths, allowing authentication bypass via a series of attempts. This was patched in 2020.7 and in a hotfix for 2019.12.