This article is based on reporting originally published at darkreading.com.
The Security Gap in Cloud-Native Development
DevOps has given organizations the automation and deployment velocity that cloud-native technologies like containers and Kubernetes make possible. But speed without integrated security creates a compounding risk: teams ship faster while security teams struggle to keep pace, often catching issues only at the end of a release cycle — or not at all.
If security is treated as a separate, final-stage gate rather than a continuous discipline woven throughout the software delivery lifecycle, organizations end up with the worst of both worlds: slower releases and a wider attack surface. The answer is DevSecOps — shifting security left so that it becomes a shared, automated, and continuous responsibility across development, operations, and security teams.
Why Containers and Kubernetes Change the Security Equation
Traditional security tooling was designed for relatively static infrastructure. Containers and Kubernetes introduce several characteristics that break those assumptions:
- Ephemeral workloads: Containers are short-lived. Patching a running container is considered an anti-pattern; the correct practice is to rebuild the image and redeploy. This means vulnerability management must move upstream into the image build process.
- High deployment frequency: CI/CD pipelines can push dozens or hundreds of releases per day. Manual security reviews at this cadence are not feasible.
- Dynamic networking: Kubernetes schedules pods across nodes, and IP addresses change constantly. Traditional network security tools that rely on static IP-based rules struggle in this environment.
- Declarative configuration: Kubernetes clusters are managed through configuration files. Misconfigured RBAC policies, overly permissive pod security contexts, and insecure network policies are common attack vectors that can be caught with automated policy checks.
Because of these characteristics, organizations cannot simply bolt legacy security tools onto a cloud-native pipeline and expect good results. Purpose-built, container- and Kubernetes-native security tooling is required.
Automation Is Non-Negotiable
A genuine DevSecOps model cannot exist without end-to-end automation. Security gates must be integrated into the CI/CD pipeline so they run automatically on every code commit, image build, and deployment. Key automation touchpoints include:
- Static application security testing (SAST) and software composition analysis (SCA) integrated into the CI pipeline to catch vulnerabilities in code and dependencies before an image is built.
- Container image scanning to identify known CVEs in base images and installed packages before images are promoted to a registry.
- Automated unit and functional tests that validate behaviour alongside security properties.
- Infrastructure-as-Code (IaC) policy checks to enforce Kubernetes security best practices — such as requiring non-root containers, enforcing resource limits, and validating network policies.
- Runtime security monitoring to detect anomalous container behaviour in production.
Tools That Support DevSecOps in a Kubernetes Environment
A broad ecosystem of open-source and commercial tools has emerged to address container and Kubernetes security. Some well-established examples include:
- Ansible and Kubernetes Operators for automating cluster configuration and operational tasks, reducing manual intervention that introduces human error.
- ArgoCD for applying the GitOps model to Kubernetes cluster configuration — treating cluster state as code, with all changes tracked, reviewed, and automatically reconciled. This approach makes configuration drift detectable and auditable.
- Open Policy Agent (OPA) / Gatekeeper for enforcing admission control policies that prevent non-compliant workloads from being scheduled.
- Falco for runtime threat detection based on system-call auditing inside containers.
- Trivy, Clair, or Grype for container image vulnerability scanning integrated into CI/CD workflows.
Container-optimized operating systems (such as Flatcar Container Linux or Red Hat CoreOS) are also changing how host OS security is managed, reducing the attack surface by limiting the OS to only what is needed to run containers.
DevSecOps Is Culture and Process, Not Just Tooling
Tools alone will not produce a DevSecOps culture. In many organisations, the security team still operates in isolation, reviewing code and infrastructure only at the final stage of development. This siloed model is directly at odds with the cloud-native development philosophy of continuous delivery and shared ownership.
Effective DevSecOps requires:
- Shared responsibility for security across development, operations, and security teams — not a handoff at the end of a sprint.
- Management support that signals to all teams that security collaboration is expected and valued, not a burden imposed by a separate group.
- Skill development so that developers understand basic security principles and security engineers understand container and Kubernetes environments.
- Cross-functional communication to prevent silos that slow down the pipeline and create blind spots.
Without this cultural foundation, even the best toolchain will be underused or circumvented under delivery pressure.
How to Get Started: Take Small Steps
DevSecOps is a significant organisational shift. Attempting to transform everything at once is a common failure mode. A more effective approach is to start small, demonstrate value, and expand iteratively.
1. Run a Pilot Project
Identify one project and assemble a small, cross-functional team that includes application developers, operations engineers, and a security representative. Define a limited scope: for example, adding image scanning and an OPA admission controller to an existing CI/CD pipeline for a single application.
2. Define Goals and Measurable Outcomes
Set clear goals before the pilot begins. Examples include reducing mean time to detect a vulnerable dependency, shortening the feedback loop between code commit and security finding, or reducing the number of vulnerabilities reaching production. Measure the baseline before making changes so that improvement is demonstrable.
3. Iterate and Document
Plan to iterate. The first implementation of a DevSecOps pipeline will not be perfect. Document what worked, what did not, and the business value delivered — faster time to market, fewer production incidents, reduced remediation cost — so the case for broader adoption is evidence-based.
4. Expand With Enthusiastic Advocates
Once the pilot has produced measurable results, recruit enthusiastic contributors and executive sponsors from across the development, operations, and security teams to help expand the model. Peer advocacy is more effective than top-down mandates for cultural change. Where possible, give teams the agency to adapt the model to their specific context while providing guardrails and documented best practices.
The Business Case for DevSecOps
Organisations that successfully implement DevSecOps in their container and Kubernetes workflows can realise significant improvements in both delivery speed and security posture. According to Red Hat’s Open Innovation Labs, organisations that adopted DevSecOps practices have reported substantial reductions in deployment cycle times and dramatic improvements in the speed at which functionality is validated — moving from multi-week processes to hours. (These figures are attributed to Red Hat’s Open Innovation Labs and have not been independently verified by this publication.)
Beyond raw speed, the strategic value of DevSecOps is the ability to compete in markets where customers expect both rapid feature delivery and trustworthy, secure applications. Organisations that cannot reconcile speed and security will face a growing competitive disadvantage as cloud-native architectures become the norm.
Key Takeaways
- Containers and Kubernetes demand security tooling and processes designed for ephemeral, high-velocity, declaratively managed environments.
- Automation is essential: security gates must run in CI/CD pipelines, not as manual reviews at the end of a release cycle.
- DevSecOps is as much a cultural and organisational shift as a technical one. Shared responsibility and cross-functional collaboration are prerequisites for success.
- Start with a small pilot project, measure results, document the value, and expand iteratively rather than attempting a big-bang transformation.
- Executive support and peer advocacy are both necessary to sustain the cultural change required.