Organizations can reduce security risks in containerized applications by actively managing vulnerabilities through scanning, automated image deployment, tracking runtime risk and deploying mitigating controls to reduce risk
Kubernetes and containers have become de facto standards for cloud-native application development due to their ability to accelerate the pace of innovation and codify best practices for production deployments, but such acceleration can introduce risk if not operationalized properly.
In the architecture of containerized applications, it is important to understand that there are highly dynamic containers distributed across cloud environments. Some are ephemeral and short-lived, while others are more long-term. Traditional approaches to securing applications do not apply to cloud-native workloads because most deployments of containers occur automatically with an orchestrator that removes the manual step in the process. This automatic deployment requires that the images be continuously scanned to identify any vulnerabilities at the time of development in order to mitigate the risk of exploit during runtime.
In addition to these challenges, software supply chain adds complexity to vulnerability scanning and remediation. Applications increasingly depend on containers and components from third-party vendors and projects. As a result, it can take weeks or longer to patch the affected components and release new software when a critical vulnerability is announced.
We can all agree that it’s nearly impossible to fix everything and remove all risks from an environment. However, the security gaps created by increased innovation and production can be overcome by detecting and blocking vulnerabilities using mitigating controls to reduce the risks associated with vulnerable images, tracking images through to runtime, and incident detection during runtime.
Sources of vulnerabilities
Vulnerability management is crucial to administer at the build stage in order to determine whether an image can be deployed or not. Vulnerabilities come in many varieties and from a number of types of software flaws and misconfigurations. Vulnerabilities in your image can be inherited from open source libraries, base images, and other 3rd party components—some of which are known and others have yet to be discovered.
Security risks can also originate from first-party application code. Vulnerabilities can stem from a mistake that application teams make during development, or perhaps as a result of misconfigurations like a hard-coded password that was added inside the code itself. Scanners make use of extensive databases to continuously track these vulnerabilities and misconfigurations to determine if any are present in applications and how they can be exploited.
Traditionally, vulnerability management initiatives have focused on finding and fixing critical and high vulnerabilities, as these are the most likely to be exploited. In the context of cloud-native application development, many DevOps teams are taking on security responsibilities and finding these vulnerabilities. Then, application and development teams – those with the necessary knowledge and expertise – are tasked with fixing and remediating these security issues.
This creates security gaps between vulnerabilities found by DevOps teams and the application and development teams’ bandwidth to address them. It is important to manage the vulnerabilities by identifying the impact of each issue and prioritizing them so the application and development teams have a stack rank of what they should be fixing and in what order. It is nearly impossible for these teams to fix everything, making prioritization critical to the entire deployment process and the overall resilience of the company.
Learn more: Kubernetes Vulnerability Scanning
Unfortunately, there are still instances when newly found vulnerabilities are reported for workloads that have already been deployed. Unfortunately, even if a team is doing everything possible to remediate vulnerabilities as part of their pipeline, vulnerabilities in production workloads are inevitable. However, a particular vulnerability can be mitigated by surrounding it with additional layers of security. Applying mitigating controls and policies will prevent deeper exploitation of that environment.
Mitigating controls provide a longer runway for the development teams to fix any vulnerabilities that may arise. Otherwise, you could be stalling the deployment and therefore slowing down the process of innovation and production for the business.
Tracking images from build to runtime
In managing the security gaps, it is important to track images with known vulnerabilities closely to understand which containers are being built out of those images and which containers in the environment could potentially be compromised. Once images are scanned and CVEs have been detected, it’s important to use an automated process that blocks the deployment of images with high-severity vulnerabilities. However, in certain instances, your organization might allow the deployment of images with vulnerabilities.
The next iteration of vulnerability management doesn’t just stop at finding issues but also goes beyond that to provide the context for the image, how it will be used, what compensating controls are available, and, once applied, distinguishing if they are actually issues that need to be fixed immediately. Teams are advised to continuously scan images for vulnerabilities and misconfigurations and keep track of all these issues in both build and runtime so that they can prioritize remediation and monitor any threats that could take advantage of their vulnerability management.
While vulnerability management is important in the build process, monitoring for runtime threats is an important part of a defense-in-depth security strategy. Monitoring workload behavior for indicators of compromise is an important way to identify malicious actors who may be making use of unknown or unreported vulnerabilities. If security teams detect a malicious actor that has made its way into the environment at runtime, they can bring that intelligence to the development team working on the build and recognize that there was an unknown vulnerability. The security and development team together can use forensics for the build to better understand and address the method of exploitation. Developers will use that information to plug gaps in the development and close that loop for the team.
Teams are addressing a slate of learning curve challenges as organizations have increased their adoption of cloud-native architecture, such as internal organization tensions, a vulnerability or exposure making its way to deployment, and understanding security risks. The steps in which development and security teams address prioritization, controls, tracking, and sharing detection intel are crucial for organizations to lean on for overall strong vulnerability management.
Want to learn more about how to secure and troubleshoot your cloud-native applications? Read about this and more in our O’Reilly eBook.
This article was originally posted to Container Journal in January 2023. Reposted with permission. Please see the original article here.
Join our mailing list
Get updates on blog posts, workshops, certification programs, new releases, and more!