Companies are leveraging containers on a massive scale to rapidly package and deliver software applications. But because it is difficult for organizations to see the components and dependencies in all their container images, container security risks associated with containerized delivery has become a hot topic in DevOps. This puts the spotlight on operations teams to find security vulnerabilities in the production environment.
Closely tracking the explosive growth of containers in the last couple years, Black Duck created Black Duck OpsSight—our first product that gives IT operations teams visibility into their container images to help prevent applications with open source vulnerabilities from being deployed.
Black Duck isn’t the only organization to identify this trend. The National Institute of Standards and Technology (NIST) published the Application Container Security Guide in September 2017 to address the security risks associated with container adoption.
Chances are, hackers are aware of the growing popularity of containers as well, which is why we compiled eight takeaways from NIST’s report on container security so you can be proactive about vulnerabilities in your production environment.
Organizations are adopting containers to accelerate software delivery, embrace flexibility in the production environment, and move to the cloud. NIST recommends that organizations tailor their “operational culture and technical processes to support the new way of developing, running, and supporting applications made possible by containerization.”1
As an example, due to the immutable nature of containers, vulnerabilities found within those containers are not simply fixed or patched with the latest software update. Instead, the base images themselves should be updated and redeployed as new containers entirely. This is an important operational difference, which is why processes and tools might have to be adjusted: “Unlike traditional operational patterns in which deployed software is updated ‘in the field’ on the hosts it runs on, with containers these updates must be made upstream in the images themselves, which are then redeployed.”2
NIST acknowledges the benefits of containers, but cautions, “When a container is compromised, it can be misused in many ways, such as granting unauthorized access to sensitive information or enabling attacks against other containers or the host OS.”3
Just as traditional applications are vulnerable to hackers, containers can be breached. The security risk associated with vulnerabilities in containers can and should be controlled. The most effective and proactive way of doing that is by finding and removing vulnerabilities in base images.
Organizations should adopt tools that “validate and enforce compliance” of container security policies. The most advanced tools will enable this enforcement by providing a method to prevent containers with security vulnerabilities from being deployed:
“Organizations should use tools that take the declarative, step-by-step build approach and immutable nature of containers and images into their design to provide more actionable and reliable results…This should include having centralized reporting and monitoring of the compliance state of each image, and preventing noncompliant images from being run.”4
Container orchestrators are a good place to start. NIST claims, “Orchestrators should ensure that nodes are securely introduced to the cluster [and] have a persistent identity throughout their life cycle.”5
Don’t rely on traditional security tools that aren’t designed to manage the security risks associated with hundreds or thousands of containers. NIST reports, “Traditional tools are often unable to detect vulnerabilities within containers, leading to a false sense of safety.” Rather, organizations should “adopt container-specific vulnerability management tools and processes for images to prevent compromises.”6
The institute warns, “Traditional developmental practices, patching techniques, and system upgrade processes might not directly apply to a containerized environment.”7
With hundreds or thousands of containers running at the same time, finding and remediating every newly discovered vulnerability in each container can be a challenge: “An image created with fully up-to-date components may be free of known vulnerabilities for days or weeks after its creation, but at some time vulnerabilities will be discovered in one or more image components, and thus the image will no longer be up-to-date.”8
To ensure containers are secure from newly reported vulnerabilities, NIST suggests organizations “utilize a container-native security solution that can monitor the container environment and provide precise detection of anomalous and malicious activity within it.”9
Tools scale, people don’t. It only takes one vulnerable container out of thousands to cause a breach—which is why organizations need visibility into every container image simultaneously.
Traditional security solutions “may not be able to operate at the scale of containers, manage the rate of change in a container environment, and have visibility into container activity.”10
NIST suggests organizations “group containers with the same purpose, sensitivity, and threat posture on a single host OS kernel to allow for additional defense in depth.”11
If containers are grouped together based on their security and purpose, hackers will have a harder time expanding that compromise to other container groups. Smart grouping makes the breach easier to detect and contain—this starts with understanding the security risks in each container.
Be proactive about container security to prevent breaches before they happen: “Deploy and use a dedicated container security solution capable of preventing, detecting, and responding to threats aimed at containers during runtime.”12
1 National Institute of Standards and Technology, Application Container Security Guide, Sept. 2017, p. iv, “Executive Summary.”
2 Ibid., p. 13, “3.1.1 Image Vulnerabilities.”
3 Ibid., p. 17, “3.4.4 App Vulnerabilities.”
4 Ibid., p. v, “Executive Summary.”
5 Ibid., p. 24, “4.3.5 Orchestrator node trust.”
6 Ibid., p. v, “Executive Summary.”
7 Ibid., p. iv, “Executive Summary.”
8 Ibid., p. 13, “3.1.1 Image Vulnerabilities.”
9 Ibid., p. vi, “Executive Summary.”
10 Ibid.
11 Ibid., p. v, “Executive Summary.”
12 Ibid., p. vi, “Executive Summary.”