Codenotary announced TrueSBOM for Serverless, a self-updating Software Bill of Materials (SBOM) for applications running on AWS Lamda, Google Cloud Functions and Microsoft Azure Functions that is made possible by simply adding one line to the application source code.
A good container has to do at least two things well: hold what it's supposed to hold, and not leak. That's true of digital containers that hold applications as well.
So if you're thinking of adopting a technology like containers, one obvious question ought to be: Does it mitigate or reduce security risks and leaks of an organization's data?
Containers are increasingly popular, for good reason. They offer multiple benefits, including portability, easy deployment, and consumption of fewer system resources. But they are also effectively a new layer in the application stack, which requires a new way of thinking about application security. In its Application Container Security Guide, NIST points out that as containers revolutionize application deployment, organizations must adapt their security strategies to new, dynamic production environments.
That's because containers and the applications they hold can be just as vulnerable to attacks as traditional applications. To design an effective container security strategy, organizations first need to understand the risks that attackers could exploit to make them leak. If you don't know the risks, how can you avoid them? Here are a few:
All isolations are not created equal. Container isolation differs significantly from virtual machine (VM) isolation. In VM systems, hypervisor isolation limits the ability of an attacker to move laterally within an application stack if an application is breached.
But containerized applications don't require hypervisors; they share elements of the host operating system's kernel. Some organizations worry, understandably, that if they deploy container-based applications, a breach could expose more of their sensitive data than it would if they used VMs (since different containers running on the same server could have access to different data).
The dynamic nature of containers introduces new runtime complexities that application deployment teams must understand and manage. Container orchestration systems like Kubernetes are designed to quickly provision replicated instances of a container image. Containerized applications consist of one or more container images coupled to form the functionality required by the application.
This leads to the topic of application scalability — a function of the quantity of specific container images deployed at any given point. When a new feature is ready for deployment, the application owner creates an update strategy to ensure any existing users of the application aren't affected by the update. This update strategy defines the percentage of images to roll forward with the update, as well as how a rollback might occur if errors are discovered.
Also, the dynamic nature of containerized deployments makes monitoring for malicious behavior or unauthorized access more difficult than in a traditional IT environment. Containerized applications often have different resource requests that are shared at the host server level.
To overcome that difficulty, IT operations and security teams should become partners with their development teams. Information sharing among them will help them understand expected behavior for the application.
Most container applications are created from base images — essentially limited, lightweight operating systems. Application container images combine a base image with application-specific elements, such as frameworks, runtimes, and the applications themselves. Each element is a layer within the image. The contents of these layers can harbor software vulnerabilities, which makes them an attractive attack surface.
Consequently, traditional application security that focuses on testing the application is not enough. Security testing of containerized applications must also address vulnerabilities latent within the layers of the image. This is because, unless there are restrictions to the contrary, any executable element within a container image can be executed — even if it's not part of the application's requirements.
As Tim Mackey, technical evangelist at Synopsys, puts it, "Treat each container image as if it were a full operating system, and identify security issues as you would for any virtual machine or server. Remediation of those issues will need a different process, one that takes advantage of capabilities within containerized environments."
It's not enough simply to scan container images, given that some clusters exceed 10,000 images. Organizations must continue to monitor for newly discovered vulnerabilities in any layer — without degrading performance.