The Trap of GitLab Auto DevOps "It Just Works, No Setup Needed"
The moment you enable GitLab Auto DevOps, security scans like SAST (static analysis) and DAST start running automatically. Vulnerability badges line up on the merge request screen, and teams breathe a sigh of relief: "We're already doing DevSecOps." But there's a classic trap hidden here.
Imagine a team enables Auto DevOps, and a SAST scan flags a Critical-severity vulnerability. The job itself still finishes successfully, and the pipeline stays green. The reviewer never notices the warning badge on the merge request — or prioritizes the release deadline over it — and merges anyway. The result: a container image containing the vulnerability gets built, pushed to the registry, and deployed to the production K3s cluster without a single hitch.
As GitLab's own SAST documentation explains, SAST is a tool designed to "detect vulnerabilities early in development, when the cost of fixing them is lowest." In other words, SAST's role is strictly detection — whether that detection is wired into the pipeline's pass/fail criteria to actually enforce anything is left entirely to how the user designs their pipeline.
What makes this worse is that, as of 2026, Auto DevOps is no longer the "we handle everything for you" product it once was. GitLab has deprecated several of the managed applications Auto DevOps used to provide in-cluster, such as Prometheus and WAF, shifting toward operators bringing their own ingress, Prometheus, Cilium, and so on. The assumption that "just turning it on gives you a safe pipeline" no longer holds.
"Passing CI" and "Safe to Deploy" Are Not the Same Thing
Why does this trap keep happening? The root cause is that the security boundary of your CI/CD pipeline and the security boundary of your Kubernetes cluster are two completely separate things — and that fact gets overlooked.
Container image vulnerability risk is far from a problem limited to a handful of popular images. According to Chainguard's research, "The State of Trusted Open Source Report," 96.2% of detected CVE instances occur outside the top 20 most widely used images. In other words, you should assume that unknown risk is always lurking somewhere in the mix of dependencies your organization actually uses.
As Wiz's security analysis points out, CI/CD scan results are simply too voluminous to meaningfully reduce risk without prioritization. The recommended approach is staged: keep feature-branch checks fast and non-blocking, while strictly gating Critical/High findings on pipelines heading toward production. But Auto DevOps' default configuration doesn't automatically build that "strict gate for production" for you. Detection on the CI side and enforcement on the Kubernetes cluster side only connect if you deliberately wire them together.
How you close this "gap between CI/CD and the cluster" is a hidden but important criterion when choosing a managed Kubernetes platform. If the cluster itself is a black box full of vendor-specific extensions, retrofitting a standard gating mechanism becomes difficult on its own. With a managed K3s environment like Kubo that preserves Pure Kubernetes, you can directly use the CNCF ecosystem policy engines discussed below.
Building a "Checkpoint" Between the Pipeline and the Cluster — Gate Design with Admission Controllers
The mechanism that closes this gap is Kubernetes' standard Admission Controller. According to the official Kubernetes documentation, an admission controller is defined as a component that "intercepts requests to the Kubernetes API server prior to persistence of the resource, but after the request is authenticated and authorized." In other words — no matter how loose your CI pipeline is, you can still apply a final check the moment a request reaches the cluster's API server.
What can admission controllers actually enforce? According to Wiz's explanation, you can consistently enforce cluster-wide policies such as restricting image pulls to approved registries only, rejecting pods that run as root, and rejecting pods that expose host ports. By splitting the roles — CI scanning handles "detection," admission controllers handle "enforcement" — you finally close the gap where something was detected but the actual harm was never prevented.
Kubo Cloud runs on a Pure Kubernetes setup that doesn't hide the API server behind a vendor-specific management layer, so you can install and run standard policy engines like Kyverno or OPA Gatekeeper (introduced next) as-is, without extra licensing constraints. GitOps support comes standard as well, making it easy to manage your policy definitions themselves under ArgoCD or Flux.
From Detection to Enforcement — Three Implementation Patterns
There are several admission controller options, but regardless of which you choose, there are three implementation patterns worth prioritizing. The first thing to tackle is the highest-priority blocking gate.
1. Turn image verification into a blocking gate (top priority)
Kyverno, a CNCF Graduated project, has a feature that verifies that the cluster only accepts signed and attested images. Similarly, OPA Gatekeeper's ConstraintTemplate lets you enforce policy logic written in Rego/CEL as reusable Constraints across the entire cluster. Getting a single rule in place at this layer — "reject unsigned, unscanned images" — is the highest-ROI first step you can take.
2. Minimize RBAC for CI service accounts
In setups where the CI pipeline deploys directly to the cluster, that service account's permissions are often far too broad. The official Kubernetes RBAC good practices recommend preferring namespace-scoped RoleBindings over ClusterRoleBindings, and avoiding wildcard permissions. Limiting the blast radius to a single namespace in advance is essential in case a CI service account is ever compromised.
3. Never put secrets in a plaintext ConfigMap
API keys and DB connection info passed as CI/CD variables should be managed with Kubernetes Secrets or an external secrets manager like Vault — not ConfigMaps. It's unglamorous, but combining this with an admission-controller policy that "rejects sensitive data written anywhere other than Secrets" gives you both halves of detection and enforcement.
Conclusion
There's nothing wrong with GitLab Auto DevOps' "it just works when you enable it" convenience on its own. The problem is mistaking that convenience for "the cluster is safe too." Only by clearly separating detection on the CI side (SAST/DAST) from enforcement on the cluster side (admission controllers), and deliberately designing a "checkpoint" between the two, does a DevSecOps pipeline actually become effective.
Start by applying one policy to your production cluster with either Kyverno or OPA Gatekeeper that rejects unsigned images. From there, expand step by step into RBAC minimization and a review of your secrets management — and the gap between CI/CD and the cluster will steadily close.
If you're looking for a foundation where you can run these standard policy engines without lock-in, Kubo is a K3s-based Pure Kubernetes platform that lets you implement the same design at over 40% lower cost than EKS/AKS. GitOps and Helm are supported out of the box too, so automating policy rollout is easy to get started with. Check out the pricing plans to see the cost breakdown, or get in touch to talk it through.