Topic starter
02/08/2026 12:28 pm
TL;DR: Container security risks increase across build, deployment, and runtime when teams rely on repo scanning alone, trust public base images, or treat misconfigurations as secondary issues, according to Checkmarx. The governance gap is not visibility in code, but failure to assess the fully built artifact and its identity and access exposure before production.
Editorial analysis by NHI Mgmt Group, based on content published by Checkmarx: “4 Common Container Security Misconceptions (and How to Avoid Them)”.
By the numbers:
- Modern development now powers nearly 90% of cloud-native applications globally.
Key questions
Q: Where do container security controls fail when teams scan only source code?
A: They fail at the point where the build process changes the software state.
Q: Why do misconfigured permissions and exposed secrets make container environments easier to exploit?
A: Containers often move quickly and run at scale, so small mistakes can create broad exposure.
Q: What are the signs that container security controls are failing in production?
A: Warning signs include repeated image drift, unexpected processes, abnormal network flows, replicas that no longer match expected behavior, and suspicious access to Kubernetes APIs or etcd.
Practitioner guidance
- Scan the built container image before deployment Assess the fully assembled image, not only the repository or Dockerfile, so hidden packages, inherited layers, and runtime-only risks are visible before release.
- Maintain a pre-approved base image library Allow teams to build only from curated images that have been reviewed for age, provenance, and vulnerability exposure, then refresh that library on a defined schedule.
- Treat container misconfigurations as access issues Review root execution, role scope, exposed services, and hardcoded secrets together, because each of these can turn a workload into an identity and access weakness.
Bottom line: Container risk is introduced across the pipeline, not only in source code, because the build process can add dependencies, layers, and secrets that scanning the repo never sees.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 1:27 pm
Container security has become a lifecycle governance problem, not a scan problem. Code scanning is only one checkpoint in a chain that now includes image assembly, registry trust, deployment policy, and runtime observation. If the fully built image is not assessed, teams are governing source code while leaving the production artefact outside control. Practitioners should treat the container image as the real security boundary.
A few things that frame the scale:
- Kubernetes production adoption has surged from 66% in CNCF's 2023 survey to 82% in 2025.
A question worth separating out:
Q: How should organisations govern container security across build and runtime?
A: They should treat container security as a lifecycle, not a point-in-time scan. That means checking source, image, infrastructure-as-code, and runtime separately, while using least privilege and secrets separation to keep one failure from becoming an environment-wide compromise.
👉 Read our full editorial: Container security fails when teams scan code but not images