Key takeaways
- Container security needs to cover the entire software lifecycle, from base images and CI/CD pipelines through to runtime monitoring and continuous remediation.
- The strongest container security strategies focus on reducing attack surface early by using trusted images, least privilege, network segmentation, and secure secrets management.
- Continuous rebuilding, vulnerability scanning, image signing, SBOMs, and runtime monitoring help teams stay secure as new CVEs and threats emerge.
Containers were supposed to make software easier to build, ship, and scale. Easier. And in many ways, they have. But they have also introduced a whole new set of security challenges that most engineering teams are still struggling to keep up with.
Images age quickly and new CVEs emerge every day, for example. What’s more, Kubernetes environments continue to grow more complex, and AI-generated code is making it more straightforward for insecure dependencies to slip into production.
That means that teams need to implement vulnerability management protocols for base images, CI/CD pipelines, runtime behavior, Kubernetes policies, image provenance, secrets management, and ongoing remediation.
In this guide, we break down 15 container security best practices that can help enterprise engineering teams reduce risk across the entire container lifecycle.
Before we begin: What exactly is container security?
Container security is the set of standards, processes, and actions involved with safeguarding containerized applications from cybersecurity threats across the entire software development lifecycle (SDLC), from development and deployment to runtime.
Typically, container security involves securing the following vulnerable areas:
- The container image: This is done by using trusted base images, scanning images for vulnerabilities, minimizing container size, verifying images, and so on.
- The runtime environment: By limiting privileges where possible, reinforcing runtime profiles, enabling read-only file systems, and limiting container capabilities.
- The orchestration platform: By using access controls, setting strict network policies, enabling audit logging and more.
- The host system security: By hardening the host OS, keeping the kernel up to date, using namespaces and cgroups properly, and so on.
Engineering and DevSecOps teams can fuse container security into their software development and security strategy by ensuring container security processes, like image scanning and policy checks, are fully integrated in the CI/CD pipeline.
15 container security best practices for enterprise engineering teams
Container security is the result of hundreds of small decisions made across the software lifecycle, from the images you trust and the secrets you manage through to runtime monitoring and Kubernetes policies.
The following best practices are designed to help engineering teams reduce risk at every stage of container development and deployment.
1. Use minimal, trusted base images to improve your container image security
Images are one of the weakest points for container security. You can help mitigate the risk by minimizing the image itself.
Minimal images matter because every extra package creates another possible attack path. Smaller images reduce attack surface, lower patching overhead, and make it easier to understand what’s running in production.
A common mistake
Many teams pull the first image they find from a public registry and build on top of it. Others rely on large base images packed with shells, package managers, and tools that are never actually needed in production.
The bottom line is this: One bloated base image reused across dozens of services can create hundreds of unnecessary open source vulnerabilities.
What to do instead
When using base images, ensure they are from a trusted source. Use official Docker images, hardened runtimes, distroless images, or curated internal images that have already been reviewed.
Where possible:
- Use slim or distroless variants
- Remove unnecessary tools and utilities
- Standardize around approved base images
- Continuously rebuild images to prevent stale packages
- Maintain a curated catalog of trusted open source components
2. Keep your container images up to date, scanning them early and often
Container images age quickly and new CVEs are disclosed every day. Even images that were considered secure a few weeks ago can quickly become a liability.
The longer an image sits without being rebuilt or updated, the more risk it accumulates. Outdated images also create larger remediation backlogs when teams eventually need to patch them.
A common mistake
Some engineering teams build an image once and continue to deploy it for months without revisiting what’s inside it. They might also rely on outdated base images, stale dependencies, or old language runtimes because updating them feels disruptive to their workflow.
The result is a growing backlog of vulnerabilities that security teams struggle to keep up with.
What to do instead
Treat container images as short-lived artifacts, not permanent assets.
Where possible:
- Rebuild images regularly
- Replace outdated base images
- Update packages and language runtimes
- Automate image refreshes in CI/CD
- Continuously scan for newly disclosed vulnerabilities
3. Apply least privilege to containers and orchestrators for containerization cyber security
Giving each component the bare minimum access it requires to function properly within your application is a key part of minimizing risk and moving towards secure containerization.
By applying least privilege, you ensure that if someone does manage to obtain unauthorized access, the damage they can do is limited and more controlled.
A common mistake
Don’t run containers as root or grant broad Linux capabilities. Don’t also use overly permissive Kubernetes RBAC policies because it’s easier than locking everything down properly.
What to do instead
Apply least privilege everywhere.
Where possible:
- Run containers as non-root users
- Drop unnecessary Linux capabilities
- Avoid privileged containers
- Limit Kubernetes RBAC permissions
- Restrict service accounts and API access
4. Secure the entire CI/CD pipeline with container security best practices
Your containers are only as secure as the pipeline used to build and deploy them. If your CI/CD process is compromised, attackers can inject malicious code, tamper with images, steal secrets, or push unsafe artifacts into production.
As AI-generated code increases development velocity, CI/CD pipelines are becoming a more attractive target for supply chain attacks.
A common mistake
Many organizations focus heavily on securing runtime environments while overlooking the build pipeline itself. This creates opportunities for attackers long before a container ever reaches production.
What to do instead
Secure every stage of the pipeline.
Where possible:
- Store sensitive information or secrets like API keys, tokens, and passwords in secret managers or vaults
- Use tools to sign images and verify signatures before deploying
- Isolate your build environments
- Keep your CI/CD tools up to date
- Build from source
5. Implement runtime threat detection for proactive container protection
Runtime threat detection gives you visibility into suspicious behavior like privilege escalation, unusual network activity, unauthorized processes, or crypto mining attacks. This is especially important because attackers often target workloads after deployment, when traditional scanning tools are no longer enough.
A common mistake
It’s easy to stop monitoring once a container passes a vulnerability scan. Unfortunately, this means suspicious runtime activity often goes undetected until after damage has already been done.
What to do instead
Extend your container security beyond the build phase.
Where possible:
- Monitor running containers for unusual behavior
- Raise the alarm on unexpected outbound connections
- Detect privilege escalation attempts
- Track unauthorized process execution
- Use runtime protection tools alongside image scanning
6. Enforce Kubernetes security best practices and policies
Kubernetes environments introduce additional layers of complexity and risk. Misconfigured clusters, weak RBAC policies, exposed dashboards, and overly permissive workloads can all create opportunities for attackers.
Security policies help teams ensure that only compliant workloads are allowed to run.
A common mistake
It can become all too easy for enterprise engineering teams to rely on default Kubernetes settings or to allow workloads to run without validating whether they meet security requirements. Additionally, it’s easy to ignore rule definitions around pod behavior, network access, or privileged containers.
What to do instead
Use Kubernetes policies to create stronger guardrails.
Where possible:
- Restrict pod behavior and permissions
- Limit network access between workloads
- Prevent privileged containers from running
- Use admission controllers and policy engines
- Enforce RBAC and namespace segmentation
7. Segment container networks for improved container protection
We’ve mentioned this before, but bad actors who are able to break into a container and then move laterally to attack other containers can wreak havoc on your apps. Since many containers can communicate openly by default, you may not even realize that the containers you’re using within your apps are vulnerable.
To combat this, ensure strict network segmentation by reviewing your containers to set rigid rules and limit which containers are able to speak to each other.
A common mistake
Oftentimes, teams will allow containers to communicate freely with one another by default. And because there are few restrictions in place, a compromised container can quickly become a path into other workloads, services, or sensitive systems.
What to do instead
Review and restrict network communication between workloads.
Where possible:
- Use Kubernetes network policies
- Restrict unnecessary outbound internet access
- Segment workloads by team, function, or environment
- Limit access to sensitive internal services
8. Practice strong container image security by signing and verifying images
The source of your images matters. It matters a lot, in fact. Before deploying an image, teams need confidence that it came from a trusted source. They also need assurances that the image has not been tampered with and contains only approved components.
Image signing and verification help to establish trust and reduce the risk of malicious or unapproved artifacts entering production.
Common mistake
It’s typical for teams to pull unsigned images from open source registries without validating where they came from or whether they’ve been modified. This creates unnecessary risk and makes it harder to prove image integrity later.
What to do instead
Strengthen trust in every image you deploy.
Where possible:
- Using trusted image sources
- Signing images before deployment
- Verifying image signatures in CI/CD
- Rejecting unsigned or untrusted images
- Combining image signing with SBOMs and provenance data
THE 2026 STATE OF VULNERABILITY MANAGEMENT | CONTAINER SECURITY EDITION
9. Regularly audit and monitor container activity
Container security is not a set-it-and-forget-it type of practice. New vulnerabilities, misconfigurations, and suspicious behaviors emerge constantly, which means teams need continuous visibility into what’s happening across their environments.
For large engineering teams, regular auditing and monitoring help them catch issues earlier and respond faster.
Common mistake
Many teams only review their container environments after an incident has already happened. Others scan infrequently because they assume their existing images remain secure over time. This creates blind spots and allows security debt to build quietly in the background.
What to do instead
Make continuous auditing part of your container security process.
Where possible:
- Regularly scan images and workloads
- Monitor for suspicious activity
- Audit Docker and Kubernetes configurations
- Review permissions and access controls
- Automate vulnerability monitoring and alerts
10. Manage secrets securely in containerized environments
Containers often need access to API keys, credentials, certificates, and tokens in order to function. But if those secrets are exposed in images or environments, attackers can use them to move deeper into your systems. Hardcoded secrets can often remain hidden in images and repositories for months or years before anyone even notices.
A common mistake
Storing secrets directly in Dockerfiles, Kubernetes manifests, Git repositories, or container images because it’s convenient during development is a recipe for disaster. Unfortunately, those secrets often end up in production and stay there indefinitely.
What to do instead
Treat secrets as dynamic assets rather than static configuration details.
Where possible:
- Use secret managers or vaults
- Avoid hardcoding secrets in images or source code
- Rotate credentials regularly
- Limit access to sensitive secrets
- Audit environments for exposed credentials
11. Treat containers as immutable infrastructure
Containers are built to be disposable and repeatable. When teams make manual changes to running containers, environments begin to drift away from what was originally tested and approved. This creates inconsistencies. It also makes troubleshooting harder and introduces hidden security risks.
A common mistake
Many teams patch running containers in production or make one-off configuration changes without updating the source image. This means that, over time, development, staging, and production environments all begin to look slightly different.
What to do instead
Treat containers as immutable assets that should always be rebuilt instead of modified.
Where possible:
- Rebuild and redeploying rather than patching live containers
- Store configuration in version control
- Use infrastructure-as-code practices
- Eliminate manual changes wherever possible
- Keep environments consistent across development and production
12. Limit container resource usage to prevent abuse
Containers should not have unlimited access to CPU, memory, storage, or other system resources. Without limits in place, a single compromised or poorly configured workload can consume far more than it should. Unfortunately, this can lead to outages, performance issues, and denial-of-service scenarios.
A common mistake
Deploying workloads without setting CPU or memory limits because it’s easier allows applications to scale more freely. The problem is that unrestricted workloads can impact other services if they consume too many resources.
What to do instead
Set clear resource boundaries for every workload.
Where possible:
- Apply CPU and memory limits
- Restrict storage usage
- Use Kubernetes quotas and limits
- Prevent individual containers from monopolizing resources
- Continuously monitor resource consumption
13. Prevent privileged containers from running
Privileged containers have elevated access to the host system and can bypass many of the security boundaries that containers are supposed to provide. If a privileged container is compromised, attackers may be able to gain access to the host itself.
A common mistake
Many teams run containers in privileged mode because certain workloads require extra permissions or because it’s the fastest way to get something working. This often grants far more access than the application actually needs.
What to do instead
Avoid privileged containers unless there is a clear and unavoidable reason.
Where possible:
- Run containers with the lowest permissions possible
- Drop unnecessary Linux capabilities
- Block privileged mode by default
- Use policy engines to prevent risky workloads
- Review workloads regularly for excessive privileges
14. Use software bills of materials to improve visibility and compliance
Software bills of materials (SBOMs) help teams understand which packages, libraries, and dependencies exist inside a container image. This makes it easier to identify vulnerable components, investigate incidents, and respond to compliance requests.
A common mistake
Many teams deploy images without maintaining any clear record of what’s inside them.
What to do instead
Generate SBOMs for every image you build and deploy.
Where possible:
- Track all dependencies and components
- Use SBOMs during audits and investigations
- Link SBOMs to image signing and provenance
- Update SBOMs whenever images change
- Use SBOM data to prioritize remediation
15. Build from source whenever possible
Prebuilt binaries can save time, but they also create blind spots. Teams often have limited visibility into how a package was built, which dependencies were included, or whether the artifact has been tampered with.
Building from source gives teams more control over what enters production.
A common mistake
Many teams rely entirely on prebuilt packages, public binaries, and opaque third-party artifacts without validating how they were created. This increases supply chain risk and makes it harder to trust what is running.
What to do instead
Where possible, start securely and build from source to improve visibility and control.
Where possible:
- Build critical components internally
- Validate dependencies before use
- Reduce reliance on unknown binaries
- Maintain trusted build pipelines
- Track provenance for all artifacts
The ActiveState Edge: Start Secure and Stay Secure
Most teams focus on finding vulnerabilities only after they’ve already entered production. By then, security teams are left chasing CVEs, triaging alerts, and working through growing remediation backlogs.
A stronger approach is to start secure from the beginning. Instead of pulling unknown packages from the open internet, teams can build from a trusted foundation of vetted open source components, hardened images, and known-good dependencies.
That foundation also needs to stay secure over time. Container images need regular rebuilds, dependencies need continuous updates, and remediation workflows need to fit naturally into CI/CD pipelines.
With ActiveState, teams can reduce their attack surface by more than 70% through access to continuously updated container images, built-from-source transparency, and the market’s most comprehensive catalog of vetted open source components.
If you want to learn more about how ActiveState can help you secure your containers from build to runtime, book a demo today.
Why container security matters more than ever
Containers have fundamentally changed how software gets built. They help teams move faster, scale more easily, and ship applications more consistently across environments.
But speed has a downside.
As enterprise engineering teams continue to rely on containers (as well as on more open source packages and more AI-generated code), it’s easy for the attack surface to keep growing. And every new image, dependency, registry, and pipeline introduces another possible point of failure.
That’s why container security can no longer be treated as a one-time and siloed scan before container deployment. It needs to be something that’s baked into the entire software lifecycle, from the base image and build process all the way through to runtime monitoring and continuous remediation.
The teams that get this right are the ones reducing risk before a container enters production. They’re also the ones building from trusted components and creating repeatable processes that make security easier to maintain over time.
To learn more about container security best practices and how to move beyond one-time vulnerability scanning toward continuous remediation, connect with an ActiveState expert today.
Frequently Asked Questions
These FAQs answer some of the most common questions security leaders have about container security, image hardening, runtime protection, and how to move beyond scan and pray toward continuous remediation.
Container security is the practice of protecting container images, registries, runtimes, orchestration environments, and the software supply chain that feeds them. That includes securing everything from base images and Dockerfiles to Kubernetes clusters, CI/CD pipelines, runtime behaviour, and open source dependencies.
The modern SDLC is no longer human-scale. With AI generating code faster than teams can manually review it, attack surfaces are expanding faster than most organizations can control. For security leaders managing 500 to 1,000 developers, container risk is no longer theoretical. It is a direct threat to security posture, delivery velocity, financial position, and personal liability. 
Some of the most common container security risks include pulling untrusted images from public registries, running outdated dependencies, giving containers excessive privileges, exposing secrets, skipping runtime monitoring, and relying on one-time scans instead of continuous remediation.
When a container runs as root, any successful compromise gives an attacker elevated privileges inside the container. In some scenarios, that can become a path to host-level compromise, lateral movement, or container escape. Running as a non-root user is one of the simplest ways to reduce the blast radius of an attack.
Docker rootless mode allows both the Docker daemon and containers to run without root privileges on the host. It reduces the risk that a compromised container can gain privileged access to the underlying system, making it an important control for teams looking to limit exposure.
Docker Content Trust is a signing and verification mechanism that helps teams confirm that an image came from a trusted source and has not been tampered with. In a world where open source packages and public images can be poisoned or manipulated, provenance matters.
The more software you include in an image, the larger your attack surface becomes. Minimal images reduce the number of packages, binaries, and dependencies inside a container, which means fewer CVEs, fewer patches, and fewer opportunities for attackers to exploit dormant components.
A minimal image is simply smaller. A secure image is intentionally built, continuously maintained, signed, rebuilt, and monitored over time. Plenty of minimal images still contain vulnerable or untrusted packages. Smaller does not automatically mean safer.
Container images should be scanned continuously across the SDLC. A one-time scan during build is not enough because new vulnerabilities emerge constantly. Teams should scan during CI/CD, at the registry level, before deployment, and in production.
