How To Make Continuous Security Work For You: Extending DevSecOps Into the CD Pipeline

This article is based on a post originally sourced from forbes.com (2019). Some statistics cited reflect research available at the time of publication.

The Speed-Security Tension in Modern Software Delivery

Accelerating application release cycles is one of the defining challenges of the cloud-native era. The most competitive engineering organizations ship software in minutes, which means developers are producing code at a pace that was unimaginable a decade ago. To keep up, operations teams rely on continuous integration (CI) and continuous delivery (CD) pipelines that never stop moving.

Speed is only part of the equation. Reliability and security must travel alongside it. As Kubernetes adoption has grown exponentially, so has the attack surface it presents. Rapid adoption frequently outpaces security maturity, and many organizations place too much trust in the default security tooling provided by their cloud-native platform alone.

Research cited in the original source found that a high percentage of Kubernetes users were leaving sensitive information exposed in production code — and industry reports have consistently identified misconfiguration and data exposure as the most common cloud security incidents. Whether or not those exact figures still hold, the underlying problem remains well-documented: security is an afterthought in too many delivery pipelines.

CI vs. CD: Understanding the Security Gap

The most important distinction for anyone building a DevSecOps strategy is that CI and CD are fundamentally different processes — and they have different security requirements.

• Continuous Integration (CI) covers compiling, testing, and building code into deployable artifacts. Security checks at this stage include static analysis (SAST), dependency scanning, and secrets detection in source code.
• Continuous Delivery (CD) covers shipping those artifacts to target environments with specific configurations and settings. Security at this stage must validate the runtime environment, Kubernetes configurations, network policies, and admission controls against a live cluster.

Many tools marketed as “CI/CD security” are, in practice, CI security tools. They perform well during the build phase but offer little or no purpose-built coverage for the delivery phase. Studies of IT and container security professionals consistently show that security tops the list of container strategy concerns, with misconfiguration and runtime risks cited most frequently — yet many organizations have no robust CD-specific security plan in place.

What CD-Specific Security Actually Requires

In a Kubernetes-driven environment, the CD phase introduces a distinct set of security checks that either cannot be performed during CI or would produce inaccurate results if attempted there. These include:

• Secret management validation: Verifying that application secrets provisioned for Kubernetes workloads are correctly scoped, not overly permissive, and not inadvertently exposed.
• Pod and container communication checks: Confirming that pods and containers are communicating only as intended, and detecting anomalous behavior that could indicate a breach.
• Security configuration drift detection: Identifying changes to Kubernetes resource definitions or cluster state that deviate from a known-good security baseline.
• Admission control enforcement: Using Kubernetes admission controllers to reject or mutate non-compliant workloads before they reach production.
• Cluster hygiene automation: Continuously auditing RBAC policies, network policies, and resource configurations as part of the delivery workflow rather than as a periodic manual review.

Automating these checks natively within the CD pipeline — rather than bolting them on as manual gate reviews — is the only way to maintain both security and delivery velocity at scale.

Tools and Approaches Worth Evaluating

Several categories of tooling address the CD security gap. No single tool covers every requirement, and most mature pipelines combine approaches.

Open Policy Agent (OPA)

Open Policy Agent is a CNCF-graduated open-source policy engine that enforces context-aware policies across the stack. In a Kubernetes context, OPA (often deployed as Gatekeeper) integrates with the Kubernetes admission control webhook to evaluate resource requests against a policy library before they are persisted to the cluster. OPA uses the Rego declarative language for policy authoring, which allows teams to define and version-control security guardrails alongside application code.

Kubernetes-Native Security Scanners

A category of lightweight, API-based Kubernetes security scanners has emerged specifically to address multicluster security, vulnerability scanning, secrets hygiene, and compliance checks against published Kubernetes and service-mesh best practices (such as Istio security guidelines). These tools integrate into the CD pipeline rather than running only at build time, giving delivery teams continuous visibility into runtime posture without requiring manual cluster audits.

CI/CD Platforms With Native Security Integrations

Platforms such as CircleCI support integration with third-party security tools at multiple pipeline stages via orbs and API hooks. When combined with purpose-built CD security tooling, they allow teams to assemble a unified pipeline where security gates are applied at both the CI build phase and the CD delivery phase without requiring two separate toolchains to be maintained manually.

Building a Practical Continuous Security Framework

A workable continuous security framework for a Kubernetes-based delivery pipeline typically combines the following layers:

1. Shift-left in CI: Static analysis, dependency vulnerability scanning, secrets detection in source code, and container image scanning before artifacts are promoted.
2. Policy-as-code in CD: Admission controller policies (via OPA/Gatekeeper or a similar engine) that enforce security baselines on every deployment, not just at build time.
3. Runtime monitoring: Continuous behavioral monitoring of running workloads to detect drift from the expected state and flag anomalies for investigation.
4. Automated remediation paths: Where possible, automated rollback or quarantine triggered by policy violations, reducing mean time to remediation without requiring manual intervention during an incident.
5. Audit and compliance reporting: Centralized, pipeline-generated evidence of security checks for compliance requirements, reducing the cost of audit preparation.

The goal is a framework where neither the CI phase nor the CD phase is a blind spot — and where security is a native property of the pipeline rather than a periodic external review.

Key Takeaways

• CI and CD have distinct security requirements. Tools purpose-built for CI are not sufficient substitutes for CD-specific security coverage.
• Kubernetes deployments introduce runtime and configuration risks that can only be meaningfully validated against a live cluster during the CD phase.
• Policy-as-code approaches (OPA, Gatekeeper) and Kubernetes-native scanners are practical starting points for extending security into CD without sacrificing delivery speed.
• A mature DevSecOps posture requires continuous security across the entire pipeline — not just a gate at the beginning of the build process.
• Automation is non-negotiable at scale. Manual security reviews inserted into a continuous delivery pipeline will either create bottlenecks or be bypassed under delivery pressure.

Choosing the right combination of open-source and commercial tools depends on your team’s scale, compliance requirements, and existing toolchain. The priority is ensuring that the CD phase is not left uncovered — because your pipeline does not stop, and neither do the threats targeting it.