Kubernetes CI/CD: modern DevOps pipelines

GitOps, ArgoCD, Tekton and security: the complete guide

Traditional CI/CD pipelines, Jenkins on VMs, SSH deployment scripts, manual configuration, generate three chronic pathologies, configuration drift between environments (production diverges from staging with no traceability), no reliable rollback (going back requires manual intervention and state diagnosis), and limited scaling (adding a Jenkins runner means provisioning a VM, configuring the network and installing dependencies). CI/CD modernisation is among the reasons platform teams most often give for moving to Kubernetes, alongside infrastructure savings and high availability.

Adopting Kubernetes for CI/CD changes the approach radically: pipelines become declarative Kubernetes resources (CRDs), isolation happens at pod level rather than VM level, and automatic horizontal scaling replaces manual provisioning. Cloud-native tools, Tekton for CI, ArgoCD for CD, Kaniko for unprivileged builds, implement the GitOps pattern, where Git is the single source of truth. This article details the three pillars of Kubernetes CI/CD (native tooling, GitOps, security), sets out progressive migration strategies from legacy pipelines, and proposes a deployment framework validated in multi-tenant production.

What comes from Hikube, and what comes from the ecosystem. Hikube provides the CNCF-conformant cluster, the image registry and the VPC; Argo CD, Flux, Kyverno and the pipeline tools named here are ecosystem components you install and run in your own cluster. Choosing between them is yours, and none of them is a catalogue feature. Managed scope: managed Kubernetes, registry, Container Registry.

The three key advantages of Kubernetes for CI/CD

Migrating CI/CD to Kubernetes brings three structural benefits that amply offset the higher initial complexity.

1. Isolation and reproducibility: from VM to pod

Traditional Jenkins pipelines run on shared VM agents where dependencies (Java, Node.js, Python) accumulate project after project. A pipeline needing Node 18 can fail because the agent previously ran a build with Node 16 that installed incompatible global packages. Resolving it needs SSH access to the agent, manual cleanup and a restart, 15 to 30 minutes of interruption per incident.

Kubernetes isolates each build in a dedicated pod with a specific container image. The Java pipeline runs in maven:3.8-openjdk-17, the Node pipeline in node:18-alpine, with no risk of cross-contamination. The pod terminates after the build, returning the environment to a clean state for the next one. This isolation removes the "works on my machine" class of failure by construction: a build can no longer inherit state left behind by the previous one.

CI/CD comparison: VM against Kubernetes pod

Jenkins VM agent:

• Setup time, 2-5 minutes (boot plus agent connection)
• Isolation, weak (dependencies shared between builds)
• Scaling, manual (provision new VMs)
• Cleanup, needs periodic maintenance
• Idle cost, 24/7 if agents are permanent

Kubernetes CI pod:

• Setup time, 10-30 seconds (image pull plus pod scheduling)
• Isolation, strong (dedicated pod per build, automatic cleanup)
• Scaling, automatic
• Cleanup, pod terminated means resources released immediately
• Idle cost, zero

Reproducibility follows directly from isolation, a build generating image app:v1.2.3 today will generate exactly the same image tomorrow, because it runs in the same container with the same frozen dependencies. Legacy VM pipelines suffer from temporal drift: system updates, security patches and tool installations progressively alter the environment, making builds non-reproducible.

2. Elastic scaling: absorbing peaks without extra cost

A Jenkins pipeline with 10 fixed VM agents, busy running actual builds say 30% of the time, still pays for all ten around the clock. Peaks (feature branches merged at the end of a sprint generating 50 simultaneous builds) exceed capacity, and builds queue for 15 to 45 minutes. The traditional answer: provision 20 permanent agents, doubling the cost to absorb occasional peaks.

Kubernetes pods appear and disappear elastically with load. A cluster with a Horizontal Pod Autoscaler (HPA) keeps 3 baseline CI pods (normal load), scales to 25 pods during peaks in 90 seconds, then scales back to 3 after 10 minutes of inactivity. Cost reflects real consumption exactly: 3 pods × 22 hours/day plus 25 pods × 2 hours/day ≈ 116 pod-hours/day against 240 VM-hours/day (10 VMs × 24h), a 52% saving.

Tekton, a cloud-native CI framework, exploits these capabilities natively. Each PipelineRun creates ephemeral pods for its tasks, terminated automatically after execution. The gain comes from removing permanently idle resources: a fleet of agents sized for the peak is paid for at the peak around the clock, a pool of pods is paid for the work actually run. How large the gain is depends entirely on your peak-to-average ratio, so compute it on your own readings.

3. GitOps: Git as the single source of truth

Traditional pipelines work imperatively, a script runs kubectl apply -f deployment.yaml to deploy, with no guarantee that the cluster state matches the Git manifest afterwards. Manual changes (kubectl edit deployment for an urgent hotfix) create invisible drift: the cluster diverges from Git, and nobody knows exactly which version is running in production.

GitOps inverts the model, Git stores the desired state (Kubernetes manifests), and an agent (ArgoCD, Flux) continuously synchronises the cluster towards that state. Any manual change to the cluster is detected and reverted automatically (self-healing). According to the CNCF 2025 survey, ArgoCD holds 60% of the GitOps market with a Net Promoter Score of 79 and 97% of users in production (against 93% in 2023).

The measurable advantages: complete traceability (every production change is a Git commit with author, timestamp and review), trivial rollback (revert the Git commit, ArgoCD synchronises automatically), simplified disaster recovery (recreate the whole cluster from the Git repo). MTTR falls mechanically once rolling back is a git revert on a state already written down, rather than a manual rebuild: how far it falls depends on where you start.

Reference architecture: Tekton plus ArgoCD

The modern Kubernetes CI/CD architecture separates responsibilities strictly, Tekton handles CI (build, test, image publishing), ArgoCD handles CD (deployment, manifest sync). That separation respects the GitOps principle: CI never deploys directly, it only commits changes to the Git repo.

Tekton, cloud-native CI

Tekton, a CNCF Continuous Delivery Foundation project, implements CI through Kubernetes Custom Resource Definitions (CRDs). The key concepts: Task (a reusable atomic step, git clone, maven build, docker push), Pipeline (a sequence of chained tasks), PipelineRun (a concrete execution instance of a pipeline), Workspace (storage shared between the tasks of a pipeline).

Minimal Tekton Pipeline example:

apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
  name: build-and-push
spec:
  params:
    - name: git-url
      type: string
    - name: image-name
      type: string
  workspaces:
    - name: source-code
  tasks:
    - name: clone
      taskRef:
        name: git-clone          # Tekton catalog task, version 0.9
      params:
        - name: url
          value: "$(params.git-url)"
      workspaces:
        - name: output
          workspace: source-code
    - name: build-image
      taskRef:
        name: kaniko             # Unprivileged build, catalog 0.6
      runAfter:
        - clone
      params:
        - name: IMAGE
          value: "$(params.image-name)"
      workspaces:
        - name: source
          workspace: source-code

Versions and prerequisites. The manifest uses the tekton.dev/v1 API, available since Tekton Pipelines v0.44 and carried by the 1.x line, v1.15 LTS since August 2026. Both taskRef entries point to catalog tasks, to be installed in the cluster before any run: git-clone 0.9 (required param url, workspace output) and kaniko 0.6 (required param IMAGE, workspace source). Install with tkn hub install task git-clone and tkn hub install task kaniko. You also need a PipelineRun that supplies the source-code workspace, a volumeClaimTemplate for instance, and a registry secret for the push. Expected result: the PipelineRun reaches Succeeded and the image is pushed under $(params.image-name). This manifest was validated syntactically and structurally (declared params, task references, workspace bindings); it was not executed on a cluster.

Tekton Hub provides 300+ reusable tasks, git operations, language-specific builds (Maven, Gradle, npm), container builds (Kaniko, Buildah), security scans (Trivy, SonarQube), notifications (Slack, email). Organisations create custom tasks for specific workflows and share them through an internal Tekton Hub.

Kaniko deserves particular attention: a tool for building Docker images without a Docker daemon and without root privileges. Traditionally, building an image needs a Docker daemon with socket access (/var/run/docker.sock), introducing security risk. Kaniko builds images directly from a Dockerfile inside an unprivileged container, ideal for secure Kubernetes pipelines.

ArgoCD: GitOps CD automation

ArgoCD, a graduated CNCF project, implements GitOps for Kubernetes. It runs as a controller inside the cluster, polling the configured Git repos periodically (every 3 minutes by default), comparing the desired state (Git manifests) with the actual state (cluster resources), and synchronising the differences.

The ArgoCD architecture comprises: Application (a CRD defining the source Git repo, path, destination cluster and sync policy), AppProject (a logical grouping of applications with RBAC and quotas), ApplicationSet (automatic generation of multiple applications from templates). The web interface exposes a real-time dashboard showing: sync status per application (Synced, OutOfSync, Unknown), health status (Healthy, Progressing, Degraded, Suspended), and synchronisation history with the associated Git commits.

1. Complete GitOps workflow, Tekton plus ArgoCD:
   1. Developer pushes code → GitHub
   2. GitHub webhook → triggers the Tekton EventListener
   3. Tekton Pipeline:
      • Clone the source code repository
      • Run the tests (JUnit, pytest)
      • Build the image (Kaniko)
      • Push the image → container registry (tag, git-sha)
      • Update the image tag in the Git manifests repository
      • Commit and push the manifests repository
   4. ArgoCD detects the new commit in the manifests repository
   5. ArgoCD syncs:
      • Compares Git manifests against cluster state
      • Applies the changes (rolling update deployment)
      • Watches replica state (replicas ready)
   6. Application deployed, ArgoCD status, Synced and Healthy

Separating the source code repository from the manifests repository is an essential good practice. The manifests repo contains only Kubernetes YAML (deployments, services, configmaps) with precise image references (app:sha-abc123 rather than app:latest). That separation allows independent rollback, more granular access control and better auditability.

Integrating with GitLab CI and GitHub Actions

Organisations that already have GitLab CI or GitHub Actions pipelines can adopt Kubernetes for CI/CD progressively, without rewriting their workflows entirely. The hybrid strategy: GitLab or GitHub handles orchestration (triggers, conditionals, approvals), while Tekton runs as the backend for Kubernetes-native tasks.

GitLab CI can trigger a Tekton PipelineRun with kubectl create -f pipelinerun.yaml, wait for completion with tkn pipelinerun logs --follow, and read the exit status. GitHub Actions offers an official tektoncd/actions action that simplifies the integration. For example: a GitHub Actions workflow triggering Tekton for the build, then ArgoCD for deployment, without leaving the GitHub interface.

CI/CD security in Kubernetes, five pillars

Kubernetes CI/CD security needs a multi-layer approach covering images, secrets, RBAC, network policies and admission control.

1. Secure images and vulnerability scanning

Every container image used in the pipelines (base images, application images) must pass a vulnerability scan before deployment. Trivy, a CNCF open-source scanner, detects CVEs (Common Vulnerabilities and Exposures) in images, filesystems and Git repos. Integrating Trivy as a Tekton task blocks the pipeline when critical CVEs are found.

Official base images (alpine, debian-slim) receive regular security patches but applications must be rebuilt to benefit. The automated rebuild strategy: Renovate Bot or Dependabot automatically create pull requests when new base image versions are published, triggering CI pipelines that validate compatibility before merge.

2. Secret management: Vault, Sealed Secrets, External Secrets

Storing secrets (passwords, API keys, certificates) in clear text in Git manifests violates GitOps principles and security good practice. Three approaches emerge: HashiCorp Vault (an external vault injecting secrets into pods at runtime), Bitnami Sealed Secrets (encrypted secrets that can be committed to Git and decrypted cluster-side), External Secrets Operator (synchronising secrets from AWS Secrets Manager, Azure Key Vault and others).

External Secrets Operator (ESO), a CNCF incubating project, unifies integration with 20+ secret backends. ESO synchronises external secrets into native Kubernetes Secrets, letting applications consume them through volumes or environment variables with no code change. The workflow: secrets are stored in AWS Secrets Manager, the ESO SecretStore points at AWS, an ExternalSecret defines the AWS secret to K8s Secret mapping, and ESO syncs automatically with a configurable refresh period (1 hour by default).

3. Strict RBAC: limiting access by role

The Tekton and ArgoCD ServiceAccounts must hold minimal permissions (the principle of least privilege). A Tekton task building images needs get/list pods (to monitor build pods) and create secrets (for registry credentials), but NOT delete deployments or create clusterroles.

ArgoCD RBAC distinguishes: Project Admin (create and delete applications within a project), Project Developer (sync applications but not delete them), Read-Only (view status). Multi-tenant organisations create AppProjects per team with RBAC isolating them: team A can only sync applications in the team-a-* namespaces, team B is limited to team-b-*.

4. Network Policies: isolating the pipelines

Tekton pods running in the tekton-pipelines namespace do not need access to every namespace in the cluster. Network Policies restrict the traffic: pipelines can reach the container registry (egress on port 443 to registry.company.com) and the Git server (port 22 SSH), but stay blocked from production namespaces.

A default "deny all" policy, all traffic is blocked except explicitly authorised flows. This zero-trust approach stops a compromised pipeline (through a malicious dependency in a build, for example) from pivoting to production services.

5. Policy enforcement: OPA Gatekeeper, Kyverno

Kubernetes admission controllers validate resources before creation. Open Policy Agent (OPA) Gatekeeper and Kyverno implement policy-as-code blocking dangerous configurations: pods requesting privileged, true, containers running as root (runAsUser, 0), images without precise tags (image, app:latest instead of app:v1.2.3).

An example Kyverno policy blocking unsigned images, verify image signatures through cosign/sigstore, reject any PipelineRun referencing unverifiable images. That policy forces teams to sign their images after the build (through cosign sign), guaranteeing provenance and integrity.

The five mistakes that compromise Kubernetes pipelines

1. Reusing Docker-in-Docker (DinD) without hardening

Symptom: using the Docker-in-Docker pattern (a container with a Docker daemon) to build images in Kubernetes pipelines, by volume-mounting the Docker socket /var/run/docker.sock from the host node.

Impact: access to the Docker socket is effectively root access on the host node. An attacker compromising a pipeline can escape the container through the Docker socket, run privileged containers, and control the whole node. CVE-2019-5736 (runc escape) shows the severity. The mechanism is direct: a build that reaches the Docker socket holds the daemon's rights on the node, which opens a path for lateral movement in the cluster. Kubernetes security audits recommend never exposing the Docker socket to untrusted workloads.

Fix: adopt Kaniko or Buildah for daemon-free builds. Kaniko builds images in a standard unprivileged container with no host access. Buildah is similar, maintained by Red Hat. To migrate: replace the docker build task with the Kaniko task from Tekton Hub (gcr.io/kaniko-project/executor), no Dockerfile change is required. Test the builds in staging before production. An advanced alternative: Google Cloud Build or AWS CodeBuild (managed services removing build infrastructure management).

2. Storing secrets directly in Git manifests

Symptom: committing secrets (database passwords, API keys) in clear text into Kubernetes Git manifests, relying on a private repo for security.

Impact, Git history exposes the secrets indefinitely, even after deletion (short of a destructive rewrite). Developers with repo access can exfiltrate production secrets. Accidental leaks (repo made public, laptop stolen with a local clone, screen sharing during a demo) expose critical credentials. A leak can stay invisible for a long time, and the secret rotation that follows needs coordination across several teams. We publish neither an average detection time nor an incident cost: the figures circulating on the subject are not comparable with one another, and yours depends on your own secret surface.

Fix: never commit secrets in clear text. Adopt External Secrets Operator (ESO): secrets stored in AWS Secrets Manager, Azure Key Vault or HashiCorp Vault, synchronised into Kubernetes. Workflow: create the secret in the backend, define an ExternalSecret, and ESO creates the Kubernetes Secret automatically. Alternative: Sealed Secrets (client-side encryption, cluster-side decryption). To migrate: audit the Git history (tool, truffleHog), rotate every exposed secret, and roll out ESO progressively.

3. Ignoring resource requests and limits on CI pods

Symptom: deploying Tekton PipelineRuns without defining CPU and memory resources.requests or resources.limits, letting pods consume cluster resources without constraint.

Impact, a Maven build consuming 8 GB of RAM with no limit can trigger an OOM (out of memory) on the node, affecting other workloads. Conversely, CPU-intensive builds can monopolise the CPU and degrade application performance. The absence of requests prevents the scheduler from placing pods correctly. The result: production incidents caused by CI pipelines, the noisy-neighbour effect.

Fix: define requests and limits systematically on Tekton tasks. Rule of thumb: requests equal typical needs (CPU 500m, memory 1Gi for a standard build), limits are a safety cap (CPU 2, memory 4Gi maximum). Use LimitRanges to impose defaults. Monitor the real metrics (Prometheus container_cpu_usage_seconds_total, container_memory_working_set_bytes) and adjust requests and limits on the observed P95. For highly variable builds (Maven on large projects), create tasks with resource tiers: small (1 CPU/2Gi), medium (2 CPU/4Gi), large (4 CPU/8Gi).

4. Manual ArgoCD synchronisation only

Symptom: configuring ArgoCD with syncPolicy.automated, null (disabled), requiring a manual sync through the UI or CLI for every manifest change.

Impact: the GitOps promise (Git as source of truth, automatic synchronisation) is no longer met. Git commits stay undeployed until a human intervenes, creating drift between Git and the cluster. Urgent fixes then need manual intervention (outside working hours, for example), which slows deployment considerably. Rollbacks suffer too: a Git revert is made, but the deployment only applies at the next manual trigger. Without automatic synchronisation, the deployment delay becomes that of the next human intervention, not that of the pipeline.

Fix: enable auto-sync with self-heal for non-production applications, syncPolicy, automated, prune, true selfHeal, true. Prune mode removes resources deleted from the Git repo, and self-heal automatically corrects any cluster-side drift. For production: enable auto-sync without prune first (a validation phase), then enable prune after a few weeks. Add deployment windows (sync windows) and notifications (Slack, email) to frame the changes. Monitor the ArgoCD metric argocd_app_sync_total and alert if an application stays OutOfSync for more than 15 minutes.

5. Neglecting disaster recovery and manifest backups

Symptom: relying solely on the Git manifests repository for disaster recovery, without backing up the ArgoCD metadata (Applications, AppProjects, RBAC, configuration) or testing the restore procedures.

Impact, if the cluster is lost (major incident, ransomware, etcd loss), the applications have to be recreated manually in ArgoCD. The process can take several hours for dozens of applications, with a high risk of error (wrong namespace, missing credentials, configuration mistakes). Losing the access configuration (RBAC, SSO) slows recovery further. Unprepared organisations see real RTOs of 12 to 24 hours against a 2 to 4 hour objective.

Fix: put automated ArgoCD backups in place through an argocd-backup CronJob exporting the resources to external storage (S3, Azure Blob, and so on). Use argocd admin export to generate a complete backup. Test the restore regularly (quarterly, for example) on a test cluster. Document a disaster recovery runbook detailing the steps, commands and access needed. An advanced alternative: use ApplicationSet with a Git generator, which recreates the Applications automatically from Git.

Progressive migration, from Jenkins to Tekton plus ArgoCD

A big-bang migration (rewriting every pipeline at once) generally fails, through team overload and business risk. An incremental approach over 12 to 16 weeks reduces the risk and demonstrates value quickly.

Phase 1 (weeks 1-3): infrastructure and pilot

• Install Tekton (Tekton Pipelines plus Triggers) through Helm
• Install ArgoCD through the official manifests
• Configure an image registry (internal Harbor or a cloud registry)
• Select a pilot application (a simple, low-criticality microservice)
• Create a Tekton pipeline, clone → build → test → push image
• Create an ArgoCD Application to deploy from Git
• Validate the full flow, commit → build → automatic deployment

Phase 2 (weeks 4-8), progressive expansion

• Migrate 5 to 10 applications a week
• Create a library of reusable Tekton tasks
• Standardise the Git repository structure
• Train the teams (workshops plus documentation)
• Implement monitoring (Grafana, pipeline metrics)

Phase 3 (weeks 9-12), security and governance

• Deploy External Secrets Operator
• Migrate the existing secrets
• Implement the policies (Kyverno, OPA)
• Configure ArgoCD RBAC per team
• Enable auto-sync and self-heal
• Set up ArgoCD backups

Phase 4 (weeks 13-16), optimisation and Jenkins decommissioning

• Analyse the metrics (lead time, MTTR, deployment frequency)
• Optimise the pipelines
• Migrate the remaining critical applications
• Progressively shut down Jenkins
• Document the good practices

Migration scenario, a 35-microservice B2B SaaS

What you are reading. This is not a client, nor a test we instrumented: it is a scenario built to show a realistic migration sequence and its orders of magnitude. The durations, headcounts and costs are stated assumptions, consistent with one another, not measurements. The gains at the end of the section follow from them by calculation. If you need figures for a steering committee, run the same method on your own readings: your current lead time, your CI/CD bill, your rollback failure rate.

An illustrative scenario, not a client: a Swiss B2B SaaS, 35 microservices (Java, Node.js, Python), 25 developers, Jenkins on EC2 with 12 permanent agents, CI/CD infrastructure cost CHF 8,500 a month, lead time 4 to 6 hours.

Problems identified:

• Configuration drift between production and staging (unversioned manual hotfixes)
• Complex rollbacks (custom scripts per service, failing 20% of the time)
• Jenkins agents overloaded during peaks (feature branch merges on Friday afternoon)
• Secrets scattered (Jenkins credentials, AWS Secrets Manager, hardcoded configuration)

Migration carried out (14 weeks, 1 platform engineer plus 0.5 DevOps):

Weeks 1-3: installation of an EKS cluster dedicated to CI/CD, Tekton Pipelines 1.15 LTS, Argo CD 3.5. Pilot: the "notification-service" (Node.js, low criticality). Tekton pipeline: clone → npm test → Kaniko build → Trivy scan → push to ECR. An ArgoCD Application syncs the manifests from the k8s-manifests repository. Validation: 8 successful test deploys, lead time 12 min (against 45 min with Jenkins).

Weeks 4-8: 20 services migrated (4-5 a week). A task library created: maven-build-test, node-build-test, python-build-test, trivy-scan, slack-notify. Team training: three 2-hour workshops, Confluence documentation (40 pages). Migration incidents: 3 (missing environment configs, each resolved in under 2 hours).

Weeks 9-12: External Secrets Operator plus AWS Secrets Manager (180 secrets rotated in three weeks). Kyverno policies: privileged pods blocked, signed images required (cosign), resource limits enforced. ArgoCD RBAC: 5 AppProjects (backend, frontend, data, infra, shared) with per-team permissions.

Weeks 13-14: the remaining 15 services migrated (3 of them critical). ArgoCD auto-sync enabled on all non-production environments, then in production after two weeks of observation. 10 of the 12 Jenkins agents decommissioned (2 kept for complex legacy pipelines).

Scenario results at six months:

ROI, calculated and not observed. The amounts below are a worked calculation on this scenario's assumptions, not a result measured at a customer, redo it with your own figures before taking it to a steering committee. Infrastructure saving of CHF 4,300/month × 12 = CHF 51,600 a year. Reduced incidents (MTTR -82%, drift -100%) = an estimated productivity gain of 2 FTE a year ≈ CHF 180,000. Migration investment: 14 weeks × 1.5 FTE ≈ CHF 45,000. ROI reached in under three months.

In short: three key points

Kubernetes turns CI/CD from stateful to ephemeral, from imperative to declarative

Jenkins pipelines on VMs generate three pathologies, configuration drift (environments diverge with no traceability), manual scaling (provisioning agents to absorb peaks), and no reproducibility (non-deterministic builds from temporal system drift). Kubernetes inverts that model: ephemeral pods (guaranteed isolation, automatic cleanup), elastic scaling (pods created and removed dynamically with load), declarative GitOps (Git as source of truth, continuous synchronisation through ArgoCD). CI/CD modernisation is among the first reasons given for moving to Kubernetes. The gains observed: lead time -95%, deployment frequency ×20, cost -40 to -60%.

GitOps with ArgoCD eliminates configuration drift and simplifies disaster recovery

The CNCF survey of July 2025 finds Argo CD on nearly 60% of the clusters its respondents manage, an NPS of 79 and 97% production use. GitOps inverts the deployment flow: traditionally CI pushes to the cluster (kubectl apply), creating drift when manual changes are applied. GitOps rests on a pull model: Git holds the desired state, and ArgoCD synchronises the cluster automatically. The benefits: complete traceability, simplified rollback, easier disaster recovery. Organisations adopting GitOps cut their MTTR by 45 to 60% and eliminate drift-related incidents.

Kubernetes CI/CD security requires a non-negotiable multi-layer approach

Kubernetes pipelines introduce a specific attack surface: Docker socket access (root escalation on the host node), secrets hardcoded in Git (credential exposure), CI pods without limits (a risk of unintentional denial of service). The security approach rests on several layers: secure images (Kaniko, Trivy), secret management (External Secrets Operator, Vault), strict RBAC, Network Policies, admission control (OPA, Kyverno). These measures are essential: real incidents show compromised CI pipelines affecting production. The cost of a critical security incident is estimated between CHF 15,000 and 50,000, against a few weeks of effort to secure the pipelines properly.