Generating a list of security vulnerabilities inside a container image is the first step in container vulnerability management. But a vulnerability report is just that – a first step. To manage container security risks efficiently and at scale, DevOps and DevSecOps teams need to know more than just which security risks exist inside a container image. They also require visibility into how severe each vulnerability is, whether it’s actually exploitable within their runtime environments, and so on. That, in a nutshell, summarizes what a comprehensive, scalable approach to container vulnerability management entails. For more details, keep reading as we explain why conventional approaches to container vulnerability scanning sometimes fall short, along with tips on how organizations can do better. What is container vulnerability management? Container vulnerability management is the practice of identifying and remediating container security risks. Typically, this process focuses on scanning container images to identify components that are known to be vulnerable, based on vulnerability databases such as NVD and CVE. The scans produce lists of vulnerabilities. From there, DevOps and DevSecOps teams review the scan reports, determine how to mitigate the vulnerabilities, and apply relevant fixes. Common pitfalls in container vulnerability management At first glance, the container vulnerability management process may seem easy enough: Engineers simply generate lists of vulnerabilities that impact their containers, then fix them. In reality, however, managing vulnerabilities can become a fraught task due to challenges like the following: High volume of vulnerabilities: It’s not uncommon for a single container image to be subject to hundreds of vulnerabilities. With so many risks to manage, it can become very challenging for engineers to know which container security problems to prioritize. Limited context: Many container vulnerability scanners are capable only of identifying vulnerabilities and the components associated with them. They don’t provide other key context, such as whether attackers can actually exploit a vulnerability within the container environment that the organization uses. Generic severity ratings: Along similar lines, the vulnerability severity scores that some scanners provide are based on generic severity assessments in public databases. They don’t reflect the degree of harm that a vulnerability exploit is likely to cause for a particular organization – and a risk that is severe in general may be minor or non-existent within a specific environment. This makes it challenging to know which vulnerabilities to prioritize when reviewing vulnerability reports. Lack of remediation guidance: Knowing a vulnerability exists is one thing. Knowing how to fix it can be quite another – and the more time DevOps and DevSecOps engineers have to spend figuring out how to implement a patch, the less efficient the vulnerability management process becomes. In short, container vulnerability scanners often generate a lot of “noise,” while providing limited actionability. They tell teams that they have container security issues, but not exactly how to approach the process of prioritizing and remediating those issues. Extend your AppSec strategy to protect containers Containers are running everywhere, and traditional approaches to application security don’t fully address the security risks that may impact them. Learn how to level up container security for the modern enterprise A better approach to managing container vulnerabilities This is why a modern, scalable approach to container vulnerability management requires more than simply using static scanning tools to generate lists of vulnerabilities, then leaving it up to DevOps security professionals to figure out how to react. The vulnerability management process must go further by including the following key aspects, which extend beyond running scans. Contextual scoring Rather than settling for generic severity ratings, like CVSS scores pulled from databases, DevOps and DevSecOps teams should leverage scanners that can generate contextual severity scores unique to their environment. Contextual scores factor in variables such as how a particular runtime environment is configured and what an application’s development pipeline looks like to provide highly relevant severity ratings. With this insight, teams can quickly determine which vulnerabilities matter most for them – as opposed to simply knowing which ones are considered severe for organizations in general. Runtime validation Static scanning identifies vulnerabilities by examining applications that are not running. While this is an efficient way of discovering vulnerabilities, it doesn’t tell engineers which vulnerabilities are actually active among running containers. To generate that insight, teams need runtime validation. Runtime validation provides essential context about the vulnerabilities that impact an organization in the “here and now,” based on which containers it has running. With this visibility, engineers can focus on remediating the issues that create the largest DevOps security risks – as opposed to spending their time chasing vulnerabilities that aren’t actually active. Developer feedback The more visibility DevOps engineers and developers have into the underlying issues that trigger a given vulnerability, the more efficiently they can address it. This doesn’t just save time and reduce toil; it also minimizes the time required to remediate a security issue, which in turn reduces the risk that attackers will exploit it while it remains unpatched. To this end, the container vulnerability management process should include feedback for developers about how to remediate each risk – which software library or application dependency to update, for example, and where to find relevant patches. Guidance like this is another crucial requirement for closing the gap between enterprise application security visibility and actionability. Security that integrates into software development Waiting to discover container security vulnerabilities until after developers have written and built an image is not efficient. Teams that take that approach end up having to go back to square one, updating application source code, then rebuilding images, whenever they need to address a vulnerability. A better approach is to “shift left” by identifying container security issues during the development process. For example, by providing real-time feedback to developers about which open-source container images are insecure, it becomes possible to minimize the number of vulnerabilities that make their way into an organization’s container environments in the first place – thereby saving time, improving the developer experience, and minimizing security risks. Take charge of container security The complexity of containers means that securing cloud-native apps requires a multi-pronged solution that mitigates threats from code to cloud. Protect containerized apps across all stages of the SDLC with Checkmarx One A modern, scalable approach to container security Traditional approaches to container vulnerability management lack the efficiency and scalability to work at enterprise scale. That’s why Checkmarx provides a holistic container security solution that not only identities risks, but also helps teams fix them fast. Learn more by requesting a demo.
