Vulnerable Stuff Running in Containers Still Vulnerable Stuff

It has been said – and not just by me – that encrypted malicious code is still malicious code. The encryption does nothing to change that, except possibly blind security and app infrastructure to its transport through the network.

The same is true of apps and platforms running in containers. If the app is vulnerable, it is vulnerable whether it’s running atop an OS, in a virtual machine, or nowadays, in a container. If the app is vulnerable in the data center, it’s vulnerable in the cloud. And vice-versa.

Containers aren’t designed to magically protect applications. They provide some basic security at the network layer, but the network is not the application. Applications have their attack surface, comprising its code and interfaces (APIs) as well as the protocols (HTTP, TCP) and the app stack it requires. None of which changes by adding an entry to an IP table or otherwise restricting inbound requests to those coming from the ingress to the containerized environment.

The reason I bring this up is thanks to Sonatype’s 2017 DevSecOps Survey. In it, 88% of the over 2200 respondents agreed container security was important, but only 53% leverage security products to identify vulnerable applications/OS/configurations in containers.

The first two pieces of that statistic – applications and OS – jumped out at me, because they are two of the components of a fully realized app stack that don’t necessarily change based on location or operational model (cloud, container, virtualization, etc…). An app or API with an SQLi or XSS vulnerability is not magically imbued with protection when it moves between models. That vulnerability is in the code. The same is true for platforms, which are inarguably part of the app security stack. A vulnerability in the handling of HTTP headers in Apache when running on Linux will still exist if that app is moved from a traditional, OS-based to a containerized model.

It’s important – imperative, even – that we continue to identify vulnerabilities in the full app stack regardless of where or in what form the app is deployed.

It is also just as important to keep in place those app protections already employed for traditional apps when moving to containers. A web application firewall is just as beneficial for apps deployed in containers as it is for apps deployed in the cloud as it is for apps deployed in traditional environments.

As are other the other security tools the survey found used by respondents such as static and real-time scanning solutions (SAST, DAST, IAST, and RASP). While web application firewall (WAF) use exceeds that of other tools, SAST and SCA (Source Code Analysis) are also common. SCA is a static means of rooting out problems before delivery. I’ll date myself and note that tools like lint fall into the SCA tool category, and while these don’t expose vulnerabilities resulting from the interaction of code (and with users) in real-time, they can find some of the more common mistakes made by developers that result in memory leaks, crashes, or the infamous buffer overflow.

I know what you’re thinking. You’re thinking, “Lori, I just read Stack Overflow's 2017 Developer Survey Results, and JavaScript is by far the number one preferred language of developers. And JavaScript is interpreted, so all this buffer overflow and memory leak stuff is just bad memories from the old days when you were coding in C/C++.”

Except that JavaScript – and other modern, interpreted languages – is ultimately implemented in a language closer to the circuit board, like C/C++. And as has been shown in the past, if one is clever enough, one can use that fact to craft an exploit of the system.

And even if that’s not a concern, there are plenty of other vulnerabilities in any code based on libraries used or a misused system call that breaches security on the server side. Current surveys say 80% of apps are composed from open source components. The Sonatype survey further noted that there has been a 50% increase in verified or suspected breaches related to open source components from 2014 to 2017. Many of which are written in languages that lend themselves to more spectacular mistakes, both because they are less controlled and because there are fewer and fewer developers proficient in those languages. 

The point being that any code is prone to contain vulnerabilities. And since code is the building block of apps, which are the face of the business today, it’s important to scan and protect them no matter where or how they’re deployed.

Containers or cloud. Traditional or virtual. All applications should be scanned for vulnerabilities and protected against platform and protocol exploits. Period.

Apps should be thoroughly scanned and tested during development, and then tested again in production. Both are necessary, because the Fallacy of Decomposition tells us that introducing new components changes the baseline. New interactions can force previously undiscovered vulnerabilities to the fore.

To protect apps, consider the following:

• Employ code and app analysis tools in development. Build them into the CI/CD pipeline if possible.
• Test again in production, in case interaction with other components/apps surfaces issues.
• Keep aware of protocol and platform vulnerabilities, as well as those discovered in third party libraries you may use
• Integrate a web app firewall into your architecture. Even if you don’t use it in blocking mode, it is an invaluable resource in the event a protocol/platform zero-day or library vulnerability is discovered.

Stay safe!