More than a decade has passed since Docker (the platform that brought software containers mainstream) swept onto the scene, transforming the way many organizations build and deploy applications.
Yet, when it comes to securing containers, you might almost believe that container technology is still brand-new, given the limited awareness of container security best practices among software developers.
Consider, for instance, that in a recent survey of hundreds of Spring developers, my organization found that as many as 64% are unaware that Dockerfiles (the “blueprints” used to build container images) can introduce vulnerabilities.
Another 42% reported being “completely unfamiliar” with the practice of using hardened images, meaning container images that are preconfigured to minimize security risks and vulnerability exposure.
Data points like these highlight just how large the gap remains between what development teams should be doing when it comes to container security, and what they’re actually doing.
Moving the needle on container security
But I’m not here to blame developers and demand that they simply “do better” when it comes to securing their development pipelines, container images and runtime applications.
Instead, I’d like to do something more constructive. I want to consider what, specifically, makes container security so challenging for developers, and how they can achieve better outcomes without compromising in other areas (like maintaining application efficiency or the rapid software release cycles).
Actionable solutions for better container security exist. The key is simply making sure developers have access to the tools and resources they need to take advantage of these resources.
Why developers struggle to secure containers
Virtually all developers want to build secure software. The lack of widespread awareness of container security best practices can’t be chalked up to developers simply not caring about security.
The issue instead stems from challenges like the following:
• Unique security challenges: Containerized applications are subject to unique types of risks (like privilege escalation attacks when containers run as root) that don’t apply (at least not in the same way) to other types of software. Some developers, even those skilled at building secure apps in other contexts, lack a deep understanding of container security fundamentals.
• Complex containers: A single container could contain a large number of components that interact in complex ways. Ensuring that no vulnerabilities creep in is very difficult, and it’s also the more challenging when you consider that containers can include commands to install additional software at runtime.
• Complex development pipelines: The CI/CD pipelines that developers use to build apps can involve dozens of tools, and they may produce multiple container images. Amidst all this complexity, it’s challenging to avoid mistakes like accidentally embedding a secret into a container image.
• Supply chain risks: Even for teams that are adept at securing development processes and environments, supply chain attacks stemming from vulnerabilities in software that they don’t control could place their apps at risk. (A prominent recent example was the breach of Trivy, a security scanning tool that attackers ironically exploited to break into the CI/CD environments of teams that relied on the tool to help protect their apps.)
Faced with challenges like these, it’s no surprise that some development teams fall short when it comes to securing containers. There are more risks to manage than the typical team can easily handle on its own. And, although tools like container image scanners can help, they alone are no guarantee that vulnerabilities won’t find their way into containerized applications.
Actionable practices for improving container security
So, what can developers do to conquer these challenges? There is no singular or simple solution, but a variety of practices can help:
- Formalize container security processes: Formalization means making security a core part of software design, testing and post-deployment processes. Rather than treating container security as something that teams can “tack on” or manage on an ad hoc basis, they should make it a core part of their workflows.
- Leverage hardened images: As noted above, hardened images reduce the risk that exploitable vulnerabilities will find their way into containerized applications. Using them is a simple and effective way to boost container security without making developers’ jobs harder.
- Keep containers simple: Generally speaking, the less code you include in a container, the more secure it will be. Developers should strive to keep things simple by avoiding components that aren’t necessary. As a rule of thumb, base images should be no larger than 10 megabytes, and they shouldn’t include risky components like package managers in runtime layers (since these make it easier for attackers to install additional software)
- Know your supply chain: Often, the greatest security threats to containers lie not in the code developers write themselves, but in third-party libraries, modules, tools or other software they rely on. For this reason, it’s critical for developers to understand where third-party code exists within their development pipelines and applications, and to validate it for vulnerabilities just as extensively as they test their own code. And they shouldn’t take an ad hoc approach to supply chain visibility; they should create Software Bills of Materials (SBOMs) for every container they deploy.
- Automate, but don’t blindly trust automations: Automated tools, like container image scanners, are a valuable way to help integrate container security into development pipelines in an efficient, scalable way. However, it’s vital for developers to understand what these tools do, what their shortcomings (such as the risk of generating false-negative alerts) are and what teams must do to close the gaps. Blindly trusting that containers are secure just because a tool says they’re secure is just as bad as not running security tests at all.
- Know your environment and code: Not every vulnerability is actually exploitable. To avoid wasting time and becoming distracted from what really matters, developers should check whether vulnerable code is reachable within their containers. Prioritizing CVEs based on generic metrics like CVSS scores isn’t enough to optimize container security.
Conclusion: When it comes to container security, a better world is possible
More and more applications are running in containers, and this is not a trend that is likely to change for the foreseeable future.
Hence the critical importance for developers of finding ways to make containers as secure as they are efficient and scalable. That’s not always easy because containers present fundamentally new types of security challenges that developers aren’t always experienced in managing. But with the right strategies and tactics, it’s possible for developers to reap all of the benefits that containers stand to offer, without sacrificing security.
____
About the author: Dmitry Chuyko is a Performance Architect at BellSoft.
Join our LinkedIn group Information Security Community!
