The container security paradox

Container adoption has transformed how software is built and delivered. That same speed and flexibility, however, has dramatically expanded the attack surface. When teams pull a base image from a public registry, they do not just inherit functionality. They inherit every vulnerability, misconfiguration, and potential backdoor embedded in that image.

A single compromised dependency can silently propagate across development, staging, and production environments long before traditional scanners raise an alert.

The Tesla Kubernetes breach illustrates this paradox clearly. Attackers did not exploit a zero-day in application code. Instead, they abused misconfigured container infrastructure, exposed credentials, and insufficient runtime controls to hijack compute resources. The workloads were running, but no one was watching closely enough at runtime to detect the abuse early.

This pattern is far from unique.

High-profile incidents such as SolarWinds, Log4j, and the xz backdoor demonstrate that modern supply chain attacks do not stop at source code. Attackers target build systems, CI/CD pipelines, third-party dependencies, and live runtime environments simultaneously. Static scanning finds yesterday’s risks. Runtime-only tools detect anomalies but often lack the context needed to trace them back to the build or supply chain source.

The result is a familiar and dangerous state:

• Security teams overwhelmed by CVE noise
• Fragmented visibility across the software delivery pipeline
• No verifiable way to prove that what was built, signed, and approved is actually what is running and behaving securely in production

This is where the CleanStart and Sysdig partnership changes the equation.

By combining build-time hardening, cryptographic provenance, and image trust with deep runtime intelligence and enforcement, CleanStart and Sysdig close the most dangerous gap in container security: the blind spot between build and runtime.

Understanding the attack surface across the container lifecycle

Modern container breaches rarely exploit a single weakness. Instead, attackers chain together gaps across multiple stages of the container lifecycle, from build to runtime.

Build-time risks in the container supply chain

Risk is often inherited long before an application is ever executed. Common build-time risks include:

• Inherited vulnerabilities: Public base images frequently ship with hundreds of known CVEs
• Dependency poisoning: Malicious or compromised packages introduced into open-source ecosystems
• Build system compromise: CI/CD pipelines targeted to inject or modify code
• Lack of provenance: No cryptographic proof of how, when, or by whom software was built and signed

Without provenance, teams cannot confidently verify whether an image is safe or trusted for organizational use. This erodes trust at the foundation of the software supply chain. Supply chains have become a preferred attack vector precisely because this trust is often assumed rather than verified.

Runtime risks: Where exploitability actually matters

Once containers are running, risk shifts from theoretical exposure to real exploitability. Adversaries can leverage several runtime risk factors:

• Configuration drift: Containers deviating from approved, hardened states
• Privilege escalation: Excessive permissions and misconfigured identities enabling abuse
• Lateral movement: Compromised containers used to pivot across workloads
• Zero-day exploitation: Pre-patch vulnerabilities abused in production

Critically, not every vulnerability present in an image represents real runtime risk.

Traditional vulnerability management treats all CVEs equally, forcing teams to chase thousands of findings. Many of these are tied to libraries that are never loaded, never executed, or never reachable. The result is wasted engineering effort on non-exploitable issues while truly dangerous risks remain buried in unprioritized alerts.

Runtime reality: In-use vulnerabilities matter more than CVE counts

What matters at runtime is execution context, but those details are often difficult to capture.

Teams struggle to identify:

• Vulnerabilities in libraries present on disk but never loaded into memory
• CVEs in code paths that are unreachable or not exposed to input
• Low-risk findings that consume remediation cycles
• What actually executes in production environments

Build-time scanners alone cannot answer these questions.

The gap between build and runtime security

The disconnect between build-time security and runtime security creates a dangerous blind spot.

Build-time scanners generate massive CVE lists but provide no insight into which components execute in production. Runtime tools may detect suspicious behavior, but often lack the context to trace it back to a specific image, build process, or source commit.

Without a continuous trust chain:

• Security teams drown in noise
• Engineering teams lose clear remediation priorities
• Organizations cannot prove that what was built, approved, and signed is what is actually running

Why runtime intelligence changes the equation

Runtime intelligence bridges this visibility gap. When combined with in-use context, runtime telemetry enables teams to determine:

• Which vulnerable libraries are actually loaded in memory
• Which processes, binaries, and system calls are executed
• Which vulnerabilities are exposed to real attack paths
• Which CVEs can be safely deprioritized

This allows organizations to focus remediation efforts where they matter most: high-risk, in-use vulnerabilities.

Runtime intelligence reduces alert fatigue, accelerates patching, and lowers vulnerability backlogs and production risk. It enables a shift from volume-based scanning to risk-based, runtime-driven remediation.

CleanStart: Establishing trust at the source

CleanStart approaches container security from first principles. Starting from a clean foundation significantly reduces downstream risk. It accomplishes this through several critical capabilities.

Near-zero CVE base images

CleanStart delivers hardened container base images with a near-zero known CVE footprint at release time. This is architectural, not cosmetic:

• Minimal by design: Only essential components are included
• Continuously hardened: CIS benchmarks and industry best practices applied
• Scanned and verified: Vulnerability and malware scanning before release
• Signed for integrity: Cryptographic signatures enable verification and detection of tampering

SLSA-aligned build provenance

CleanStart aligns with Supply-chain Levels for Software Artifacts (SLSA) principles by enforcing hermetic, reproducible builds and generating cryptographically signed provenance:

• Hermetic builds: Isolated, reproducible builds designed to produce deterministic outputs from identical inputs
• Provenance attestations: Cryptographically signed metadata documenting:
  
  • Source repository and commit
  • Build system and configuration
  • Dependencies resolved at build time
  • Builder identity and timestamps
• Verifiable chain of custody: Auditors can validate not just what was built, but how it was built

Distroless and minimal images

CleanStart provides development images with debugging tools and production-grade distroless images stripped to essential runtime components only.

No shells. No package managers. No unnecessary utilities.

Custom image building

Through the CleanStart Portal, teams can request images tailored to internal standards, including:

• Operating system and version
• Application runtimes (Node.js, Python, Java, Go, etc.)
• Architectures (x64, ARM64)
• Compliance profiles (FIPS, CIS hardened)

Nothing more than required and nothing less.

‍

‍

CleanStart and Sysdig form a tightly coupled feedback loop that strengthens security posture across the container lifecycle.

Build-to-runtime traceability

CleanStart produces software bills of materials (SBOMs), cryptographic provenance attestations, and vulnerability scanning results. Sysdig consumes this metadata to validate that deployed images match verified builds, correlate runtime findings with exact component versions, and attribute suspicious behavior to specific images, layers, and source components.

Runtime-to-build feedback

Sysdig’s runtime insights inform future builds by identifying packages that are never used, prioritizing vulnerabilities actively targeted at runtime, and refining detection policies based on real-world behavior.

Verified deployment gates

Together, CleanStart and Sysdig enable:

• Image signature verification via admission control at deploy time
• Provenance validation before deployment
• Risk-based vulnerability gates
• Continuous compliance checks against policy

Sysdig: Runtime threat detection, prevention, and forensics

While CleanStart establishes trust at build time, Sysdig extends that trust into production through deep runtime visibility.

Sysdig uses eBPF-based instrumentation to monitor system calls, processes, file access, and network activity with minimal overhead and accurate workload attribution.

Falco, the CNCF standard for runtime security, applies behavioral rules to detect unexpected process execution, suspicious file system access, malicious network connections, privilege escalation attempts, and container escape techniques.

‍

‍

Sysdig also prioritizes vulnerabilities based on actual runtime exposure by correlating in-use packages with exploitability, permissions, internet exposure, and live detections. Runtime drift detection further identifies unauthorized binaries, configuration tampering, cryptomining activity, and persistence mechanisms.

Conclusion

Container security is neither a build-time problem nor a runtime problem. It is both.

Together, CleanStart and Sysdig establish a continuous trust chain from source to production. CleanStart ensures images are built cleanly and verifiably. Sysdig ensures those images behave securely in production, with runtime intelligence feeding back into stronger builds.

The outcome is not just better security. It is provable security.

Organizations can demonstrate exactly how their software was built and how it is behaving right now. In an era of accelerating software supply chain attacks, this proof is no longer optional.

Ready to learn more about securing cloud workloads from source to production?

Download our whitepaper, Your Cloud Security Strategy is Backward.