[{"data":1,"prerenderedAt":377},["ShallowReactive",2],{"blog-en-cicd-pipeline-devsecops-gate-design-four-layers":3,"blog-related-en-cicd-pipeline-devsecops-gate-design-four-layers":330,"blog-en-cicd-pipeline-devsecops-gate-design-four-layers-alt":318},{"id":4,"title":5,"author":6,"body":7,"date":312,"description":313,"extension":314,"image":315,"locale":316,"meta":317,"navigation":318,"path":319,"seo":320,"stem":321,"tags":322,"__hash__":329},"blog\u002Fblog\u002Fen\u002Fcicd-pipeline-devsecops-gate-design-four-layers.md","Still Bolting Security Checks Onto Your CI\u002FCD Pipeline Without Deciding Where They Belong? A Four-Layer Model for DevSecOps Gate Design","Kubo Team",{"type":8,"value":9,"toc":300},"minimark",[10,15,27,30,46,53,62,66,72,85,90,118,125,129,135,138,147,160,167,171,177,180,192,212,220,224,230,242,251,260,274,278,285,288],[11,12,14],"h2",{"id":13},"_1-you-adopted-sast-and-dast-so-why-do-incidents-still-reach-production","1. You Adopted SAST and DAST — So Why Do Incidents Still Reach Production?",[16,17,21],"p",{"className":18,"dir":20},[19],"content-paragraph","ltr",[22,23],"img",{"src":24,"alt":25,"width":26,"height":26},"https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fcicd-pipeline-devsecops-gate-design-four-layers\u002Fsection01.webp","","inherit",[16,28,29],{},"Investment in CI\u002FCD pipeline security has clearly grown over the past few years. Teams run SAST, scan container images, and check dependencies for known vulnerabilities — yet production incidents still happen, and not rarely.",[16,31,32,33,37,38,45],{},"The root cause is usually not the tools themselves. ",[34,35,36],"strong",{},"The design decision of which check goes where in the pipeline, and at what stage, is often never made explicit."," Palo Alto Networks defines CI\u002FCD security as \"integrating security throughout the software delivery lifecycle, rather than treating it as an isolated stage\" (",[39,40,44],"a",{"href":41,"rel":42},"https:\u002F\u002Fwww.paloaltonetworks.com\u002Fcyberpedia\u002Fwhat-is-ci-cd-security",[43],"nofollow","Palo Alto Networks Cyberpedia","). In other words, simply bolting on more tools one at a time does not, by itself, make security \"integrated.\"",[16,47,48,49,52],{},"The more tools you add, the easier it becomes to assume \"surely some stage is checking this\" — while a real gap that nobody is actually watching quietly opens up. This article reframes CI\u002FCD pipeline security not as ",[34,50,51],{},"addition, but as placement design",", introducing a four-layer model and walking through concrete implementation patterns for K3s\u002FKubernetes environments.",[16,54,55,56,61],{},"As pipelines grow more complex, the operational burden of continuously maintaining this design decision grows too. We'll return to how to reduce that burden — together with how ",[39,57,60],{"href":58,"rel":59},"https:\u002F\u002Fkubo.hexabase.io\u002F",[43],"Kubo"," fits in — in the implementation section later in this piece.",[11,63,65],{"id":64},"_2-design-a-devsecops-pipeline-around-four-layers","2. Design a DevSecOps Pipeline Around Four Layers",[16,67,69],{"className":68,"dir":20},[19],[22,70],{"src":71,"alt":25,"width":26,"height":26},"https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fcicd-pipeline-devsecops-gate-design-four-layers\u002Fsection02.webp",[16,73,74,75,78,79,84],{},"A useful framework for designing CI\u002FCD pipeline security is the ",[34,76,77],{},"four-layer model",". Microsoft's engineering blog describes governance across four layers for DevSecOps design on AKS (",[39,80,83],{"href":81,"rel":82},"https:\u002F\u002Ftechcommunity.microsoft.com\u002Fblog\u002Fazureinfrastructureblog\u002Fdevsecops-on-aks-governance-gates-that-actually-prevent-incidents\u002F4508415",[43],"Microsoft Tech Community",").",[86,87,89],"h3",{"id":88},"what-each-layer-does","What each layer does",[91,92,93,100,106,112],"ul",{},[94,95,96,99],"li",{},[34,97,98],{},"Pre-deployment (CI)",": Fast feedback and guardrails for developers. Catches problems at commit time and before merge.",[94,101,102,105],{},[34,103,104],{},"Admission Control (governance gate)",": The layer that forcibly blocks anything from entering the cluster. This layer is assumed to be \"unskippable.\"",[94,107,108,111],{},[34,109,110],{},"Runtime Protection",": Detects and responds to anything that slipped through. Not a substitute for the gate — the last line of defense.",[94,113,114,117],{},[34,115,116],{},"Continuous Compliance",": Drift detection and auditing. Continuously verifies that configuration hasn't quietly changed after the fact.",[16,119,120,121,124],{},"What this article wants to emphasize in particular is the asymmetry the same blog post points out: \"CI scans can be skipped, but Admission Control cannot be skipped unless the cluster's configuration itself is broken.\" In other words, ",[34,122,123],{},"the same check can have completely different real-world effectiveness depending on which layer it sits in",". A design that relies on CI alone can collapse from a single branch-protection misconfiguration or an emergency bypass.",[11,126,128],{"id":127},"_3-the-pre-deployment-layer-what-should-be-caught-early","3. The Pre-deployment Layer: What Should Be Caught \"Early\"?",[16,130,132],{"className":131,"dir":20},[19],[22,133],{"src":134,"alt":25,"width":26,"height":26},"https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fcicd-pipeline-devsecops-gate-design-four-layers\u002Fsection03.webp",[16,136,137],{},"The purpose of the Pre-deployment layer is \"fast feedback for developers,\" so the checks placed here need to prioritize execution speed and developer experience above all else.",[16,139,140,141,146],{},"OWASP's CI\u002FCD Security Cheat Sheet is explicit that secrets should \"never be hardcoded in the repository or CI\u002FCD configuration,\" and recommends using an external secrets management solution along with mechanisms that detect secrets before they're committed (",[39,142,145],{"href":143,"rel":144},"https:\u002F\u002Fcheatsheetseries.owasp.org\u002Fcheatsheets\u002FCI_CD_Security_Cheat_Sheet.html",[43],"OWASP Cheat Sheet Series","). The same guidance applies to the build execution environment itself — it should run on \"properly isolated nodes,\" with a default-deny, least-privilege design recommended across pipeline secrets, cross-pipeline access, and OS-level permissions.",[16,148,149,150,153,154,159],{},"DAST (Dynamic Application Security Testing), on the other hand, targets a running application by nature, so it cannot execute at commit time. Snyk's research found that organizations running SAST and DAST together detect ",[34,151,152],{},"40–60% more vulnerabilities"," than those relying on a single method alone (",[39,155,158],{"href":156,"rel":157},"https:\u002F\u002Fsnyk.io\u002Farticles\u002Fdebunking-dast-myths\u002F",[43],"Snyk","). But DAST is fundamentally meant to run after deployment to a staging environment — running a full DAST pass on every single commit would badly damage pipeline speed.",[16,161,162,163,166],{},"In short, the Pre-deployment layer isn't monolithic. ",[34,164,165],{},"The core of the design is clearly separating \"what should return results instantly at commit time\" (secrets scanning, dependency version pinning) from \"what should be verified in a post-deployment environment\" (DAST)."," Conflate the two, and you get one of two failure modes: developers blocked from merging while waiting for DAST to finish, or secrets scanning skipped entirely and leaks going unnoticed.",[11,168,170],{"id":169},"_4-admission-control-is-the-one-layer-you-cannot-skip","4. Admission Control Is the One Layer You Cannot Skip",[16,172,174],{"className":173,"dir":20},[19],[22,175],{"src":176,"alt":25,"width":26,"height":26},"https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fcicd-pipeline-devsecops-gate-design-four-layers\u002Fsection04.webp",[16,178,179],{},"No matter how thorough the Pre-deployment layer's checks are, they only work if developers actually run them. Misconfigured CI settings, pipeline bypasses during emergency patches, PRs from forked repositories — real-world paths around CI genuinely exist.",[16,181,182,183,188,189],{},"Against this, the official Kubernetes documentation defines an Admission Controller as \"code that intercepts requests to the Kubernetes API server after authentication and authorization are complete, but before the object is persisted\" (",[39,184,187],{"href":185,"rel":186},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Freference\u002Faccess-authn-authz\u002Fadmission-controllers\u002F",[43],"Kubernetes documentation","). Processing happens across two phases — Mutating and then Validating — and if either phase rejects the request, the entire request is rejected on the spot. In other words, Admission Control ",[34,190,191],{},"has enforcement power on a layer independent of CI: outside the application, inside the cluster.",[16,193,194,195,200,201,206,207,84],{},"Two policy engines are widely used to implement this layer: Open Policy Agent (OPA) and Kyverno. According to OPA's official documentation, OPA runs as an Admission Controller for the Kubernetes API server and evaluates policy using the request type, the operation, and the full object as input (",[39,196,199],{"href":197,"rel":198},"https:\u002F\u002Fwww.openpolicyagent.org\u002Fdocs\u002Fkubernetes",[43],"Open Policy Agent documentation","). Kyverno, meanwhile, lets you write policies in the same YAML format as Kubernetes manifests, so there's no new policy language to learn (",[39,202,205],{"href":203,"rel":204},"https:\u002F\u002Fkyverno.io\u002Fdocs\u002Fintroduction\u002Fhow-kyverno-works\u002F",[43],"Kyverno documentation","). CNCF's official blog also describes how Kyverno's four functions — Validate, Mutate, Generate, and Cleanup — help teams move away from processes that depended on manual approval gates and toward automated DevSecOps flows (",[39,208,211],{"href":209,"rel":210},"https:\u002F\u002Fwww.cncf.io\u002Fblog\u002F2026\u002F03\u002F19\u002Fpolicy-as-code-flexible-kubernetes-governance-with-kyverno\u002F",[43],"CNCF blog",[16,213,214,215,219],{},"If a management platform like Rancher gives you a single, unified view of policy enforcement across multiple clusters, the operational burden of tracking \"what got rejected, and on which cluster\" drops considerably. That visibility is one factor worth weighing when choosing a K3s-based management platform such as ",[39,216,218],{"href":58,"rel":217},[43],"Kubo Cloud",".",[11,221,223],{"id":222},"_5-implementation-patterns-for-cicd-pipelines-on-k3s-kubo","5. Implementation Patterns for CI\u002FCD Pipelines on K3s \u002F Kubo",[16,225,227],{"className":226,"dir":20},[19],[22,228],{"src":229,"alt":25,"width":26,"height":26},"https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fcicd-pipeline-devsecops-gate-design-four-layers\u002Fsection05.webp",[16,231,232,233,236,237,241],{},"If Admission Control is designed in as \"the one reliably enforced layer\" rather than \"the last resort,\" the ideal is not to discover policy violations there for the first time, but to ",[34,234,235],{},"pre-validate the same policies before merge",". CLI tools like Conftest (for OPA) or ",[238,239,240],"code",{},"kyverno jp"," (for Kyverno) let you evaluate the exact same policies that Admission Control enforces, right inside the CI pipeline — at PR time.",[16,243,244,245,250],{},"Integration with a GitOps pipeline is another key design element. Argo CD's official documentation lays out the GitOps principle that \"changes to the desired configuration are pushed to Git first, and the cluster state is then synced to match,\" and describes CI pipeline integration in three stages: \"building and pushing the image to a registry,\" \"updating manifests and committing to the configuration repository,\" and \"triggering a sync via the CLI when needed\" (",[39,246,249],{"href":247,"rel":248},"https:\u002F\u002Fargo-cd.readthedocs.io\u002Fen\u002Fstable\u002Fuser-guide\u002Fci_automation\u002F",[43],"Argo CD documentation","). Separating the application's source repository from its manifest repository is also recommended, since it means CI has no direct write path into the cluster.",[16,252,253,254,259],{},"Signing container images is another important piece of protecting the supply chain. Sigstore's cosign supports keyless signing using short-lived keys backed by OIDC authentication, dramatically reducing the operational burden of key management (",[39,255,258],{"href":256,"rel":257},"https:\u002F\u002Fdocs.sigstore.dev\u002Fcosign\u002Fsigning\u002Fsigning_with_containers\u002F",[43],"Sigstore documentation","). Design Admission Control to reject unsigned images, and the Pre-deployment layer's build step and the Admission Control layer's enforcement become one continuous, connected line.",[16,261,262,263,267,268,273],{},"On K3s-based Kubo, ",[39,264,266],{"href":58,"rel":265},[43],"ArgoCD\u002FFlux integration comes built in",", so there's no need to build this GitOps integration from scratch. For industries like finance or healthcare, where full supply-chain governance and audit trails are required, an option like ",[39,269,272],{"href":270,"rel":271},"https:\u002F\u002Fwww.hexabase.com\u002Fproduct\u002Fkubo\u002Fon-premise",[43],"Kubo On-Premise"," — which lets you run the same four-layer model entirely within an air-gapped, closed network — is also worth considering.",[11,275,277],{"id":276},"_6-summary","6. Summary",[16,279,280,281,284],{},"CI\u002FCD pipeline security incidents usually stem not from a shortage of tools, but from a shortage of design. Rather than \"adding\" individual tools like SAST, DAST, and image scanning one at a time, deciding upfront ",[34,282,283],{},"what belongs in which of the four layers — Pre-deployment, Admission Control, Runtime Protection, and Continuous Compliance"," — is the shortest path to avoiding both gaps and redundancy.",[16,286,287],{},"Admission Control in particular is the one layer that, unlike CI, has no room to be skipped — which is exactly why placing policy enforcement there via OPA or Kyverno is the crux of the design. A good starting point is auditing your own pipeline and asking: \"which layer is this check actually in right now?\" and \"is it truly in a layer that can't be skipped?\"",[16,289,290,291,294,295,219],{},"You no longer need to put up with the high cost, complexity, and vendor lock-in of EKS or AKS. With K3s-based ",[39,292,60],{"href":58,"rel":293},[43],", you get the full power of Kubernetes and the same four-layer security design, at dramatically better cost efficiency. If you're rethinking your pipeline's security design, it's a good moment to rethink the operational platform underneath it too — feel free to reach out via our ",[39,296,299],{"href":297,"rel":298},"https:\u002F\u002Fwww.hexabase.com\u002Fcontact-us\u002F",[43],"contact page",{"title":25,"searchDepth":301,"depth":301,"links":302},2,[303,304,308,309,310,311],{"id":13,"depth":301,"text":14},{"id":64,"depth":301,"text":65,"children":305},[306],{"id":88,"depth":307,"text":89},3,{"id":127,"depth":301,"text":128},{"id":169,"depth":301,"text":170},{"id":222,"depth":301,"text":223},{"id":276,"depth":301,"text":277},"2026-08-28","You've adopted SAST, DAST, and container scanning — yet incidents still slip into production. This article reframes CI\u002FCD pipeline security as a four-layer design problem and walks through concrete implementation patterns for K3s\u002FKubernetes environments.","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fcicd-pipeline-devsecops-gate-design-four-layers\u002Feyecatch.webp","en",{},true,"\u002Fblog\u002Fen\u002Fcicd-pipeline-devsecops-gate-design-four-layers",{"title":5,"description":313},"blog\u002Fen\u002Fcicd-pipeline-devsecops-gate-design-four-layers",[323,324,325,326,327,328],"k3s","kubernetes","ci-cd","devsecops","admission-control","gitops","GcFafNVp0-vgaR1vIuTYQhvm3CkUlssXFoq8Jyl0O9k",[331,339,346,354,362,370],{"path":332,"title":333,"description":334,"date":335,"tags":336},"\u002Fblog\u002Fen\u002Fgitlab-auto-devops-k3s-admission-controller-gate","Why GitLab Auto DevOps' 'It Just Works' CI Is the Closest Threat to Your Production K3s Cluster","GitLab Auto DevOps runs SAST\u002FDAST automatically the moment you turn it on. But a scan 'running' and a vulnerable image never reaching your production K3s cluster are two completely different things. Here's how to build an audit gate between CI\u002FCD and the cluster.","2026-08-17",[323,324,337,325,326,338],"gitlab","admission-controller",{"path":340,"title":341,"description":342,"date":343,"tags":344},"\u002Fblog\u002Fen\u002Fkubernetes-image-signing-sigstore-supply-chain","Anyone Can Rewrite an Image Tag. Why Kubernetes Needs Sigstore-Backed Signing to Prove Provenance","Container image signing explained: tags can be overwritten by anyone, and passing CI tests doesn't guarantee the image running in production is the one you built. Learn how Sigstore and Kyverno work together to reject unsigned images on Kubernetes\u002FK3s, integrated into a GitOps workflow.","2026-08-06",[323,324,325,328,345],"security",{"path":347,"title":348,"description":349,"date":350,"tags":351},"\u002Fblog\u002Fen\u002Fcanary-release-kubernetes-auto-rollback-gitops","Why Every Team Ends Up at the Same CI\u002FCD Wall — Designing 'Safe-to-Break' Kubernetes Deployments with Canary Releases and Automated Rollback","Most production incidents happen because teams deploy everything at once. This article walks through how to design canary releases, automated rollback, and monitoring on Kubernetes using Argo Rollouts and GitOps — with practical steps small teams can actually sustain.","2026-07-15",[324,323,325,352,328,353],"canary-release","argo-rollouts",{"path":355,"title":356,"description":357,"date":358,"tags":359},"\u002Fblog\u002Fen\u002Fkubernetes-gitops-branch-antipattern-fleet-scaling","Your dev\u002Fstaging\u002Fprod Branches Are a Time Bomb: Why Kubernetes GitOps Really Breaks","Splitting dev\u002Fstaging\u002Fproduction by Git branch is a GitOps anti-pattern that undermines Kubernetes' declarative foundations. Learn why drift happens, how to migrate to a directory-based, trunk-based setup, and how to design for fleet-scale growth.","2026-08-10",[323,324,328,360,361],"argocd","devops",{"path":363,"title":364,"description":365,"date":366,"tags":367},"\u002Fblog\u002Fen\u002Fk3s-edge-fleet-declarative-management","One Device's Troubleshooting Is a Funny Story. A Thousand Devices Is a Business Risk: How Rancher Fleet Rescues K3s Edge Operations from Tribal Knowledge","Fleet management for K3s edge operations breaks down once you're troubleshooting devices one at a time by hand. Here's how declarative management and Rancher Fleet let you design edge operations that don't depend on any single person.","2026-08-03",[323,324,368,328,369],"edge-computing","fleet-management",{"path":371,"title":372,"description":373,"date":374,"tags":375},"\u002Fblog\u002Fen\u002Fqa-to-devops-kubernetes-career-transition","A QA Engineer's 'Instinct to Break Things' Transfers Directly to Kubernetes Operations: The Fastest Path from Test Automation to a DevOps Career","The quality-gate mindset and test automation skills QA engineers already have map directly onto Kubernetes operations aptitude. Here's a realistic six-month roadmap for making the switch, and how to clear the biggest obstacle in the way.","2026-07-19",[324,323,361,325,376],"career",1792488896127]