The emergence and sophistication of containers have made writing and deploying applications much easier in the last decade — but a raft of security challenges for developers also accompanies it. We’re going to briefly run through some common problems that DevSecOps, SecOps, and DevOps teams face when using containers to build software securely, and take a look at some examples of container security tools and how developers can use them to design and deploy secure software.
What’s a Containerized Application?
First off: what exactly are we talking about here? In this context, we’re referring to containers like Docker, Kubernetes (K8s), AWS Fargate, and others used by software developers to build and manage applications. This also means the tools used to secure software throughout the development lifecycle, including open-source container security tools. Containers hold a binary and all its dependencies in a self-enclosed, fully functioning digital environment. You can open a docker image, run it in AWS or Azure, and begin to develop the software while ensuring cloud security. This makes containers perfect development environments for building and testing applications — but it also means that container security has to be an absolute priority. If the container environment is in any way compromised or compromisable, the software itself, regardless of how hardened the code is, is at risk.
Why Are Applications Built in Containers a Security Risk?
Aside from performance and flexibility improvements, containers have solved numerous security problems for developers. Workloads can be isolated and applications abstracted, for starters. Containerization also benefits rapid development and testing processes that accompany Continuous Integration/Continuous Development (CI/CD), so constant changes to code, libraries, dependencies, and more are expected. However, the more frequent the changes, the greater the opportunity for errors or missed vulnerability analysis — which is a constant challenge for security teams, no matter how well-integrated.
As containers have become a mainstream method of packaging and deploying applications and dependencies, they’ve grown into a tempting cyber attack target for attackers and a vulnerability management challenge. Because AppSec and development teams must ensure software supply chain security they must be cognizant that any part of the build environment is also a potential weakness. If your container or containerized application can be compromised at any point in the process, it can be used as a carrier for attacks across infrastructures and systems. If the underlying systems it runs on are compromised, that’s another slew of problems that fall out of the scope of this article, but are vital pieces of developer knowledge.
Containers and Malware
The very scalability, flexibility, and efficiency of containers as development environments for applications make container-borne applications tempting targets for threat actors. OWASP notes that instances of malware in containerized applications are on the increase and Palo Alto Networks first reported on malware specifically targeting Windows containers as far back as 2021. Aside from these threats, common security issues such as misconfigurations, outdated dependencies, and unauthorized changes are also a challenge.
Containers & Supply Chain Security Problems
Given that applications are built and run in containers to improve efficiency and scalability, any error at the creation phase of an application can quickly turn into an AppSec problem that’s spread far and wide across multiple organizations and instances. Aside from the security issue, if your business is unintentionally spreading a security issue to its customers, this could potentially create issues of reputational damage, liability, and more — in other words, the propagation of a supply chain exploit. AppSec and operations teams must ensure the confidentiality, availability, and integrity of container images from initial development to deployment.
The Need for Container Security & Container Security Tools
It’s important to iterate that while containers improve software development efficiency, they introduce security challenges during all stages of development including runtime. AppSec teams must be aware of and using security scanning solutions to ensure they are actively scanning and monitoring their containers and applications for:
- Insecure container images: For instance, using unverified or outdated images from public registries may introduce vulnerabilities.
- Excessive privileges in containers: Running containers as “root” increases application security risks if compromised, particularly in relation to known vulnerabilities.
- Misconfigured secrets management: Hardcoded API keys, passwords, and certificates in container images can be exposed.
- Container escape attacks: For example, exploiting a vulnerable container runtime like “runc” to execute malicious commands on the host.
- Lack of network segmentation: Containers with open network policies may allow attackers to spread across environments
- Persistent data exposure: Containers often use mounted volumes that may expose sensitive data.
- Access control issues: Access control for container security is critical, and exploiting weak authentication is a preferred method of compromise, as it gives attackers access to the systems and data they are after.
The most successful way to prevent containerized applications from becoming a security threat is to use application security tools and vulnerability assessments that scan containers for vulnerabilities.
Context-rich analysis of these security assessments is vital. Vulnerabilities at all stages of the software development design, build, and deployment processes should be evaluated based on reachability, exploitability, and business impact. These analyses must occur during every phase of software development, from design through runtime, regardless of the environments used at every stage.
This process should ideally start at planning and pre-commit stages all the way through deployment to runtime as a component of existing DevSecOps, SecOps, and DevOps approaches.
Container security solutions can detect insecure configurations, spot compliance failures, and identify outdated libraries. They can also scan for vulnerabilities and check runtime security while reducing the risk of a vulnerable container-based application.
Key Aspects of Container Security Scanning Tools
It’s worth understanding at a high level what needs to be protected before we dive into specifics. Firstly, there’s the container image itself — the entirety of an application’s code, including any libraries and other dependencies it requires to function. Ensuring the whole codebase remains secure, verifiable, and protected is critical.
Containers are stored as images in registries — Gitlab is one example. Securing images with strong authentication is a must, as is regular scanning for gaps in security coverage, such as weak authentication methods, unrestricted privileges, or missing network segmentation. Orchestrators (examples include Kubernetes, but Microsoft Azure, AWS, IBM, and others are available) handle the work of running and scaling your containers.
Container images are executed using a container runtime, which sits between the host operating system and the container itself. One well-known example is containerd, the runtime used by Docker. Container runtimes help isolate containerized applications from the host, but additional security measures like SELinux and Seccomp are needed for full protection. To reduce risk, it’s crucial to regularly patch and secure the container runtime.
From Container to Deployment
This is where the abstraction that containers provide creates a bit of a disconnect between the creation and operation of an application. If looking at containers from the perspective of DevOps, then the rest of this chain is still well worth understanding, but it is more likely to fall under the remit of your organization’s security practices.
Container orchestration platforms take care of deploying and scaling, and as a result are attractive to attackers. Ensuring these security platforms move information safely and securely between containers and other environments is critical, as containers are often interconnected and can depend on the same operating system instance as other containers.
Container Vulnerability Management
Container Vulnerability Management (CVM) is a subset of container security in and of itself, and is worthy of a short explanation. CVM is a process of identifying, quantifying, and fixing container security vulnerabilities. This process requires examination of every element of the container ecosystem: hosts and orchestrators as well as the container images themselves.
It bears repeating that securing software and managing application vulnerabilities is easiest, least expensive, and most effective when issues are identified, analyzed, and triaged as early in the design process as possible. That is the entire goal of the “shift left” movement in security, and specifically, in application security posture management.
Any organization that practices DevSecOps will naturally have the security team embedded within development and operations teams. In a DevSecOps scenario, teams are already using the tools and processes that seamlessly integrate with development cycles.
Incorporating “shift left” security into containerized environments is essential. Containers, while offering benefits like scalability and consistency, can introduce unique security challenges if not properly managed. By embedding security practices early in the development process, teams can ensure that container images are free from vulnerabilities, configurations adhere to security best practices, and any potential risks are mitigated before deployment.
This “shift left” approach within container vulnerability management necessitates the use of specialized container security tools and tasks. These include static analysis tools for scanning images for vulnerabilities during the build process, dynamic analysis tools for monitoring container behavior at runtime, and image registries with integrated vulnerability scanning. Automating security checks within the CI/CD pipeline, implementing security policies for container deployments, and regularly updating base images are crucial tasks for maintaining a secure environment that is free of excessive container security risks.
Application Threat Modeling Approaches
In today’s software development landscape, containers have become a cornerstone, offering efficiency and consistency across various environments, especially with the help of security features. However, with their rise, ensuring robust security within these containerized applications has become paramount. A proactive approach to this is threat modeling, a structured method to identify and mitigate potential security risks during the development process.
To adapt threat modeling methodologies to containerized environments, the following methodologies can be tailored to address the unique aspects of containerized applications:
STRIDE framework: This prominent framework helps AppSec professionals identify and categorize potential security threats to software systems. It uses six categories – Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege – to systematically analyze and address vulnerabilities.
PASTA (Process for Attack Simulation and Threat Analysis): This framework was introduced by Tony UcedaVélez and Marco M. Morana as a risk-centric threat modeling methodology that focuses on understanding the business impact of potential attacks by simulating them and analyzing the associated threats. It emphasizes collaboration between technical and business stakeholders to prioritize threats based on their potential impact on the organization’s objectives.
Attack trees: A hierarchical, diagrammatic threat modeling technique used to decompose potential attacks into a tree-like structure. Attack trees help AppSec teams identify the various paths an attacker could take to achieve a specific malicious objective. they are also used to facilitate the analysis of attack likelihood and determine defense strategies.
Conclusion
Securing containers and the enabling systems and environments that support them must be a top priority for AppSec teams. In addition to the above, organizations should consider the following AppSec leading practices for container environments:
- Continuously assess the environment: Containers and container images require regular security scanning to identify misconfigurations, outdated libraries, and other potential weaknesses. Static analysis tools, runtime security tools, integrated platforms (such as ASPM and CNAPP), and specialized tools are key to finding then fixes the issues that matter most.
- Don’t forget about deployed software: Runtime protection is necessary to scan for abnormalities and possible intrusions in live environments. Software security doesn’t stop at deployment.
- Follow established best practices: Ensure network security best practices are followed when implementing controls and processes in containerized environments, including the use of image scanning tools. Network policies, segmentation, secure communication, ingress/egress control, strong access. Network policies, segmentation, secure communication, ingress/egress control, strong access controls, network monitoring, and more all apply to container security.
Let OX Security take on the load of securing your application containers could well save you time and money. To find out more book a demo today.
)
