Our website uses cookies

Cookies enable us to provide the best experience possible and help us understand how visitors use our website. By browsing Infosecurity Magazine, you agree to our use of cookies.

Okay, I understand Learn more

Three Pillars of Docker Security: Visibility, Identification & Tracking

Like all software, containers face security challenges. Among those challenges are exploitable software vulnerabilities in components used inside Docker containers, exacerbated by the ease with which Docker containers can be deployed.

Without tools to manage the security of Docker deployments, organizations risk exposing their containers to attack. There are three essential pillars that form container security:

  1. Establishing Container Provenance – Ensure application code within the container originated with a known and trusted publisher. Be sure you know what’s inside and where it originated. Investigate validation technology and certification options for trusting container sources.
     

Without a system in place vetting their contents, compromised or malicious container images might be distributed to unsuspecting organizations. Docker Content Trust uses public key cryptography to allow publishers to “sign” Docker containers and vouch for the integrity of the code they contain.

  1. Scanning for Vulnerabilities within Container Images – Verify that the contents of the container won’t introduce serious and exploitable security vulnerabilities.
     

Verifying the publisher of a container won’t guarantee that the software application or supporting files within the container doesn’t have exploitable vulnerabilities, of course. Your containers almost certainly include more than the applications your team builds. They also bundle the third-party software and Linux modules those apps depend on, and may be bundling outdated and insecure components.

Insight into Open Source Used in Your Containers

The challenge of managing software vulnerabilities increases in scope and complexity when hundreds – possibly thousands – of different open source software components and licenses could be part of your code base. Since 2014, more than 6,000 new open source security vulnerabilities have been reported, making it essential to have good visibility into the open source you’re using in order to understand if there are vulnerabilities in your containers.

Open source use is ubiquitous worldwide and is de facto the way applications are developed today. Open source security and vulnerability management can no longer be treated as an afterthought or isolated activity. Ignoring including open source as part application security testing puts organizations at risk of being blindsided by the next high-profile and costly security exploit.

There is considerable room for improvement in securing and managing open source. A recent Black Duck review of 200 commercial applications found that 67% had known open source vulnerabilities, more than one third of which were rated “severe.”

Static application security testing, dynamic application security testing, and run-time application self-protection (better known as SAST, DAST, and RASP respectively) are all essential for finding application vulnerabilities, particularly those rooted in custom code. But alone they provide an incomplete picture. Only a handful of the more than 6,000 open source vulnerabilities reported since 2014 were detected by traditional static or dynamic testing tools. 

Organizations need comprehensive application security solutions that can detect, manage, and monitor open source as well as custom code vulnerabilities, that can build a bill of materials, cross reference the bill of materials against vulnerability databases, and will notify the developer or operations manager if a problem exists.

  1. Creating a Process for Container Management through the Application’s Lifecycle – You must establish a security management process across the entire lifecycle of a containerized application, from development to deployment. Inspect your container contents regularly to mitigate security risks.
     

Identifying open source components and versions is essential to knowing whether you are using software that contains a known vulnerability, but you also need a process to continually update that information even after the container is deployed. Applications age, new versions are released, new vulnerabilities are discovered, all widening the potential attack surface.

Security = Visibility, Identification & Tracking

Securing your container starts with visibility into the ingredients that make up the container. Identifying the container’s open source components and versions is essential to knowing whether you are using code that contains a known vulnerability. Plus, you need a process to keep track of this information even after the container is deployed, so you can determine any impact to your container as new vulnerabilities are disclosed. 

Applications deployed via container platforms must be certified prior to deployment to ensure that the code they contain originated with a known and trusted publisher. But verifying the provenance of containerized application code is not enough. Security issues such as exploitable vulnerabilities in application components require a process in place to assess the security of your containerized applications throughout their full lifecycle.

Those three pillars – Visibility, Identification, and Tracking – coupled with sound policy management and orchestration technologies, can provide a solid solution for securely managing your containers.

What’s Hot on Infosecurity Magazine?