#Cloud Security #DevSecOps #Kubernetes #CI/CD #Supply Chain

Cloud & Platform Engineering · Cloud Security

Securing a cloud-native platform from pipeline to runtime — zero critical vulnerabilities in production

Zero critical CVEs in prod · supply chain hardened · runtime threats detected in <2 min

A SaaS company running Kubernetes in production had 14 critical CVEs in production images, 3 secrets committed to Git, and no runtime monitoring. Adimen built four security layers — supply chain, secrets management, policy-as-code, and runtime detection — and reduced critical CVEs to zero.

Challenge

Three attack surfaces with zero controls in place: a supply chain that shipped vulnerable base images into production, a CI/CD pipeline that had no policy enforcement gate, and a runtime environment with no anomaly detection or observability beyond basic uptime metrics.

Approach

Four security layers built in sequence — supply chain hardening with image scanning and signed artifacts, secrets management via HashiCorp Vault with Git leak detection, policy-as-code enforcement gates in CI/CD using OPA/Gatekeeper, and runtime security with Falco and Elastic SIEM for threat detection and response.

Outcome

Zero critical CVEs in production. Supply chain hardened end-to-end. Secrets rotated and vault-managed. Runtime threats now detected in under 2 minutes. Two enterprise contracts that had been stalled on security review were unblocked and signed within 6 weeks of completion.

0
Critical CVEs in production — down from 14 at the start of the engagement
<2 min
Runtime threat detection time — from anomaly event to SIEM alert
3
Secrets found in Git history — rotated, removed, and vault-managed
6
Weeks from start to enterprise security review cleared and contracts signed

The background

Three attack surfaces. Zero controls in place.

1 — Supply chain
Vulnerable images in prod

No image scanning in the CI/CD pipeline. Base images were pulled without version pinning or signature verification. A Trivy scan of the production images found 14 critical CVEs — several with public exploit code. No one had looked at the image contents since the service was first deployed.

2 — CI/CD pipeline
No policy gates

The deployment pipeline had no admission control. Any image that passed a build would deploy to production without a policy check. Gitleaks scanning revealed 3 secrets committed to the repository history — API keys that were still active. No pre-commit hooks or pipeline security gates existed.

3 — Runtime
No monitoring

No runtime security monitoring existed beyond basic pod health checks. There was no mechanism to detect anomalous process execution, unexpected outbound connections, or privilege escalation inside running containers. A compromise would have had an open window until someone noticed the symptoms.

What was built

Four security layers. One governed, observable platform.

Supply chain hardening

Trivy integrated into the CI pipeline as a blocking gate — builds fail on critical CVEs. Base images pinned to specific digest hashes and verified on pull. Dependabot configured for automated dependency update PRs. Docker images signed with cosign and signature verification enforced at admission. The result: no unsigned or unscanned image can enter the registry, let alone production.

Secrets management

Gitleaks added as a pre-commit hook and a CI pipeline step to prevent new secrets from entering the repository. All 3 discovered secrets rotated immediately. HashiCorp Vault deployed as the secrets backend — applications retrieve credentials via dynamic secrets with TTLs rather than static environment variables. The Git history was cleaned. No application now holds a long-lived credential in its environment.

Policy-as-code in CI/CD

OPA/Gatekeeper deployed as Kubernetes admission controller with policies covering image source restrictions, required security contexts (non-root, read-only root filesystem, dropped capabilities), resource limits, and network policy requirements. ArgoCD configured to enforce policy compliance before any deployment reaches the cluster. Every deployment is evaluated against policy — non-compliant manifests are rejected at the gate.

Runtime security

Falco deployed as a DaemonSet with custom rules tuned to the application's normal behaviour — distinguishing legitimate process patterns from anomalous ones. Alerts forwarded to Elastic SIEM for correlation, enrichment, and escalation. A runbook was built for each alert class covering investigation steps, containment actions, and escalation paths. Mean time from anomaly event to actionable alert: under 2 minutes.

Architecture

From code commit to running cluster — every layer secured.

Kubernetes · ArgoCD · GitHub Actions · AWS · Terraform Commit Git + Gitleaks Secret scan pre-commit CI/CD Trivy · Dependabot CVE gate + dep updates Registry cosign signed Pinned digests Admission OPA/Gatekeeper Policy enforcement Runtime Falco Anomaly detection Secrets HashiCorp Vault Dynamic creds · TTL rotation SIEM Elastic SIEM Correlation · alerts · runbooks

Results

Zero critical CVEs. Two contracts' worth of trust.

0
Critical CVEs in production — down from 14. Every image that reaches production is scanned, signed, and verified.
<2 min
Runtime threat detection. Falco + Elastic SIEM turns an anomaly event into an actionable alert in under 2 minutes.
3
Secrets removed from Git history, rotated, and moved to Vault-managed dynamic credentials.
100%
Policy coverage. Every deployment is evaluated against OPA/Gatekeeper admission policies — no unreviewed workload reaches the cluster.

Tech stack

Trivy Falco HashiCorp Vault Gitleaks OPA/Gatekeeper Dependabot Elastic SIEM Kubernetes ArgoCD GitHub Actions Terraform AWS

Critical CVEs in prod and no runtime visibility?
Let's fix both at once.

Get in touch →
← Back to Case studies