Benefits of open source container vulnerability scanning
Containers have revolutionized app development but pose many security challenges. Uncover how container vulnerability scanning can help and why to consider open source tools.
When it comes to application containers, such as Docker, Rkt and Mesos Containerizer, most developers will tell you two things: They've revolutionized how they do their jobs, and they're here to stay. These self-contained and portable packages of application functionality, along with any associated dependencies, help developers and operations teams streamline the release process. Developers like them because they can spend less time mirroring production platforms to ensure the software they write will perform as they expect upon release -- not to mention less time actually debugging configuration issues in production -- while the portability of containers means the right configurations travel with the application when code moves between environments.
From operational efficiency and development speed-to-market perspectives, containers have been revolutionary. From a security point of view, though, they can introduce some challenges. Primary among these challenges is that keeping track of -- and mitigating -- vulnerabilities can be extremely complex, especially as different containers may use different versions of dependent software.
Consider an environment running two different containerized applications, for example. Both containers provide services that are part of a broader application. Even though they might be written in the same language -- say, Python -- they might use a different version of the runtime, e.g., one might be Python 2.x and the other Python 3.x. Likewise, the supporting libraries in use might be different or, worse yet, different versions of the same library. There could also be different middleware, different versions of the same middleware or different configurations needed for the application to run.
This situation, while complicated, starts out manageable until, over time, vulnerabilities start appearing that affect the supporting components, libraries and middleware. To stay on top of those issues, developers and security teams need to keep track of what is installed where, what version(s) of each component is running on each container and how they interoperate, how the containers are used so as to triage issues and more. This example is with just two containers. Imagine the company that has hundreds or thousands of them. It gets very complicated, very quickly.
Enter container vulnerability scanning
In many instances, teams will turn to traditional security tools to mitigate the issues. However, using traditional security tools to address container challenges has its own challenges. Sure, traditional vulnerability scanning tools can help flag a subset of vulnerabilities but with a few major caveats. First, just like VMs, they can be ephemeral or transient -- meaning they stay in an inactive state until needed. Second, depending on the scanning configuration, there is only so much a tool can tell about installed software versions without being on the container itself. For example, it might show that a web server version needs updating but not if a given Python library does.
To address the issues with traditional vulnerability scanning tools, a new category of security tools has emerged. These tools focus on providing visibility into what containers are running and, based on this visibility, deliver information about software on the container that may contain vulnerabilities. The goal is simple: Find out what is running on a particular container, and flag anything potentially problematic.
Many commercial tools provide this functionality, but there is an array of open source tools available as well. Open source tools, such as Anchore Engine, CoreOS' Clair project and Dagda, identify vulnerable container configurations. The core of this is done by looking within the container for items on the Common Vulnerabilities and Exposures list. Depending on the configuration and specific product, they might also look for malware, unsafe configurations and other security-affecting issues.
"Containers have made it really easy to reuse software from other sources, allowing us all to create more intricate and amazing things," said Ross Turk, vice president of marketing at Anchore. "But this results in a fragmented and dynamic attack surface. Container scanning tools are freely available and can help us understand what's inside the images we build, consume and ship."
Open source security tools can offer many benefits -- even in situations where teams know they will ultimately transition to a commercial tool down the road.
Such tools are vital to looking and knowing what is inside the container. Based on what is found, tools can take further action, such as flagging specific containers for subsequent remediation, increasing monitoring of known-vulnerable containers until a fix is practicable, quarantining the container or even just alerting a developer or administrator. They can be used either by developers or automated and integrated into a release pipeline.
Advantages of open source
As most security practitioners know, open source security tools can offer many benefits -- even in situations where teams know they will ultimately transition to a commercial tool down the road.
The first benefit of open source is it lets teams kick the tires to both build up ammunition to use to pitch a business case or use during budget discussions, while also demonstrating the value security teams will receive through its use. Even if teams ultimately decide to transition to a commercial alternative, this can give you peace of mind. An Osterman Research survey found 28% of security tools end up shelfware -- in some organizations, it is as high as 60%. Demonstrating the company can and will derive value from the tool before making a purchase can help streamline conversations with executives who may worry about whether the tool will see use.
The second benefit is that having solid open source options means that teams can put something in place without having to wait for a budget cycle to complete. Acquiring budget can take a full year -- or, in some cases, years -- to get the resources needed to field a security measure. An open source option means that, provided organizations have the technical expertise in-house to stand it up, security teams don't have to necessarily wait to close a gap or mitigate a risk. This can be useful to quickly close an audit finding, as an interim stopgap to close a high-risk area or for any number of other short-term situations where getting something in place right now is paramount.
Container scanning is both valuable and, given that there are multiple open source options to accomplish it, something that can be done at minimal cost. Given that, what do teams have to lose by giving it a try?
