While the new world of IT offers a radically new way for businesses to innovate, it brings a new set of vulnerabilities due to lack of visibility, proper controls and security. And, with the vast amount of security breaches taking place today due to vulnerabilities in open source components, such as example Heartbleed, Shellshock, and Poodle, organisations are increasingly focusing on making the software they build more secure.

Addressing the constantly changing landscape of open source security threats can seem a never-ending process. As organisations increasingly turn to containers to improve application and agility, vendors have been plugging security holes while attempting to expand flexibility for container deployments.

[easy-tweet tweet=”Vendors have been plugging security holes while attempting to expand flexibility for container deployments” via=”no” usehashtags=”no”]

How container security currently works

Container providers’ main focus today is to use encryption to secure the code and software version running in Docker users’ software infrastructure to protect users from malicious backdoors in shared application images and other potential security threats. However, this method covers only one aspect of container security, excluding whether software stacks and application portfolios are free from unknown, exploitable versions of open source code.

Docker Content Trust only ensures Docker images contain the exact same bits that the developer originally put there, but does alert users of any vulnerabilities already present in the open source components. In fact, a current study by BanyanOps found that more than 30 percent of images in Docker Hub are highly susceptible to a variety of security attacks including Heatbleed and Shellshock.

Security Risk 1 – The new threats to old versions

Knowing that the container is free of vulnerabilities at the time of initial build and deployment is a necessary but insufficient requirement. New vulnerabilities that can easily impact older versions of open source components are being constantly discovered. An informed open source technology that provides selection and vigilance to users is essential to avoid this.

Security Risk 2 – Data sensitivity and container location

The security risk posed by a container also depends on the sensitivity of the data that’s being accessed by it, as well as the location in which the container is deployed.

The security risk posed by a container also depends on the sensitivity of the data that’s being accessed by it

Whether the container is deployed on the internal network behind a firewall or whether it’s internet facing will affect the level of security risk. Containers deployed on an internal network behind a firewall, for example, won’t be exposed to a publicly available attack. 

For this reason it is critical to be aware of where your open source software is located, whether the code exhibits security vulnerabilities and whether a sharp open source profile exists. In other words, having visibility of the code inside containers is critical to container security.

Will this slower down container adoption?

Analysts hold diverse opinions as to whether concerns over security will slow down container adoption.

Business necessity is likely to prevent container adoption from slowing down, as containers have proven to provide many benefits to businesses. These include improved scalability, fewer errors, faster time to market and simplified application management.

Dave Bartoletti, principal analyst at Forrester Research, believes security concerns won’t significantly slow container adoption: “With virtualisation, people deployed anyway, even when security and compliance hadn’t caught up yet, and I think we’ll see a lot of the same with Docker,”

Meanwhile, Adrian Sanabria, senior security analyst at 451 Research, believes enterprises will give containers a wide berth until security standards are identified and established. “The reality is that security is still a barrier today, and some companies won’t go near containers until there are certain standards in place”, he explains.

[easy-tweet tweet=”The presence of vulnerabilities in all types of software is inevitable says @bill_ledingham” user=”comparethecloud” usehashtags=”no”]

Whatever the case, what is clear is that security remains a concern as application container deployment ramps up. The presence of vulnerabilities in all types of software is inevitable, and open source is no exception. As security and other gaps in the container ecosystem are filled, organisations are best served to take advantage of the automated tools available to gain control over all their software infrastructure elements, including containers. Taking the lead in setting up a strong application security strategy is imperative to all business and one that they should proactively be seeking to deploy. 

Previous articleAn Introduction to Continuum
Next articlePrivate/Public Nirvana: the combination of private cloud and public data centres

Bill Ledingham, EVP of Engineering and Chief Technology Officer, Black Duck Software

Bill brings over 30 years of technology and security experience to his role as Chief Technology Officer (CTO) and Executive Vice President of Engineering at Black Duck Software.

Prior to joining Black Duck, Bill was CTO of Verdasys, a leader in information and cyber security, where he worked closely with leading Global 2000 companies and government organizations to safeguard their most sensitive information. Prior to Verdasys, he was a co-founder and VP of Engineering at Avalere, a software company focused on information management and security, which was acquired by Iron Mountain Digital. 

Bill holds a B.S. in Electrical Engineering and a M.S. in Industrial Engineering from Stanford University, and a MBA from Harvard University. Bill's honors include Tau Beta Pi, Phi Beta Kappa, and the Terman Engineering Award for graduating at top of Stanford's undergraduate engineering class.