On March 29, 2024, Microsoft engineer Andres Freund noticed a 500-millisecond delay in SSH logins on a Debian testing box and pulled on the thread until it unraveled into CVE-2024-3094 — a backdoor hidden inside xz-utils, a compression library present in nearly every Linux distribution. It took a curious engineer, not an alerting pipeline, several days of manual archaeology across tarballs, commit history, and maintainer accounts to confirm the payload and its blast radius. Most security teams don't get that lucky. When a runtime alert fires — a suspicious outbound connection from a pod, a GuardDuty finding on an EC2 instance, a Falco rule tripped by a shell spawned inside a container — the alert names an IP, a namespace, an image digest. It almost never names a commit, a pull request, or the engineer who merged it. That gap between "something bad is running in production" and "here is the exact source line that put it there" is cloud-to-code traceability, and closing it has become one of the hardest unsolved problems in application and cloud security.
What is cloud-to-code traceability, and why did 2024 make it unavoidable?
Cloud-to-code traceability is the ability to take any live cloud artifact — a container, a Lambda function, a VM image, a Kubernetes workload — and walk backward through the entire deployment chain to the exact commit, dependency, and author responsible for it. It became unavoidable because 2024 was the year the industry stopped treating supply chain compromise as theoretical: the xz-utils backdoor showed a malicious actor spending nearly three years building maintainer trust before shipping code that reached production Linux boxes worldwide, and it was caught by accident, not by process. Sonatype's annual supply chain research has tracked malicious open-source package uploads growing well into the hundreds of thousands per year, and the median enterprise now pulls dependencies through five or more transitive layers before code ever reaches a Dockerfile. When compromise and detection are separated by months and several build systems, "where did this come from" stops being a forensic nicety and becomes the whole incident response.
Why doesn't a production alert already point to a commit?
Because every layer of a modern deployment pipeline is specifically designed to strip that context away in the name of abstraction. A build system produces an image; a registry stores it by digest; a CD tool deploys it under a mutable tag like myapp:latest; an orchestrator reschedules it across nodes; and a runtime sensor eventually reports on a process ID or container ID that has no inherent memory of the Git SHA that built it. Concretely: CloudTrail and GuardDuty retain findings for 90 days by default, most CI systems retain build logs for 30-90 days depending on plan tier, and once a base image is rebuilt nightly for patching, the digest an alert references may no longer exist anywhere in a registry. Log4Shell (CVE-2021-44228), disclosed December 9, 2021, is the canonical example of what happens without this link: organizations spent weeks just inventorying which running services contained a vulnerable log4j-core jar, because no system connected "this pod is running" to "this pod's build included this dependency version."
How does a runtime finding actually map back to a Git commit?
It maps back through five discrete hops, and if any one of them is missing, the trace dies. Start with the runtime event — say a GuardDuty finding of type CryptoCurrency:EC2/BitcoinTool.B on a node backing an EKS cluster. Hop one resolves the finding to the specific pod and container image digest running on that node at the time of the alert. Hop two resolves the digest to the CI build that produced it, typically via an OCI image label or a SLSA provenance attestation recording the GIT_COMMIT or GITHUB_SHA environment variable at build time. Hop three resolves that commit SHA to the pull request that merged it — in a real incident this might be PR #4821, merged eleven days earlier by a contractor account with a valid but stale review. Hop four resolves the PR's diff to the actual change: in a case like this, a transitive dependency update pulling in a typosquatted package (reqiuest instead of request) fourteen layers deep in the tree. Hop five attributes the change to an author and a reviewer for accountability and follow-up. Done manually, this chain routinely takes analysts one to three days per incident, because each hop lives in a different tool with its own auth, retention window, and query language.
What actually breaks this chain in real environments?
The single biggest breakage point is mutable image tags: audits of production Kubernetes clusters have repeatedly found that a majority of running images — commonly cited around two-thirds — are deployed under floating tags like latest, stable, or main rather than immutable digests, which means the exact bits running today may already have been overwritten in the registry by tonight's rebuild. The second breakage point is base image churn: a base image patched for CVEs every 24-48 hours changes the digest of every downstream image without changing a single line of application code, which makes naive commit-matching produce false attributions. The third is infrastructure-as-code drift, where the Terraform or CloudFormation state that "should" describe a resource no longer matches what's actually deployed after a manual console change or an emergency hotfix. The fourth is monorepo ambiguity: in a repository with 40 services and one commit history, a single SHA doesn't tell you which of 40 deployable artifacts it produced. And the fifth is serverless and ephemeral compute, where a Lambda function might be invoked millions of times a day with no persistent container to inspect, so the runtime evidence trail that container forensics relies on simply doesn't exist in the same form.
What does a fast, complete trace actually look like?
A fast trace looks like minutes, not days, because every hop above is pre-computed and indexed continuously rather than reconstructed by hand during an active incident. In a well-instrumented environment, a runtime alert at T+0 resolves to an image digest within seconds using the container runtime's own metadata, resolves to a commit SHA by T+2 minutes via a stored SLSA provenance attestation, resolves to a PR, author, and reviewer by T+5 minutes via a maintained commit-to-PR index, and produces a ticket containing the exact diff, dependency change, and blast radius (every other service that consumed the same commit or dependency version) by T+15 minutes. Compare that to the industry baseline: IBM's Cost of a Data Breach research has repeatedly found average identification-and-containment timelines in the range of 250-plus days when the underlying cause is a supply chain or third-party component issue, precisely because that lineage work is done manually and reactively. The 2021 Codecov breach, where an attacker modified the Bash Uploader script and exfiltrated CI secrets from thousands of pipelines for roughly two months before discovery, is a case study in what happens when nobody is continuously watching the cloud-to-code link — the compromise was live in production far longer than the eventual investigation took once someone finally looked.
How Safeguard Helps
Safeguard builds cloud-to-code traceability as a standing capability, not a one-time forensic exercise. Every artifact Safeguard sees in a cloud environment — container image, serverless function, VM, or IaC-managed resource — is continuously linked to the commit, pull request, dependency graph, and author that produced it, using build provenance and SBOM data captured at build time rather than reconstructed after the fact. When a runtime or vulnerability finding comes in, whether from a cloud-native detector, a CVE feed, or Safeguard's own scanning, the platform already has the digest-to-commit-to-owner chain indexed, so the question "who do we call and what do we roll back" resolves in the time it takes to run a query instead of the days it takes to reconstruct a build history across five disconnected tools. Because Safeguard is built for multi-tenant environments and tracks lineage per tenant and per repository, it also handles the messier realities that break naive tracing — mutable tags, nightly base image rebuilds, monorepos with dozens of deployable services, and IaC drift — by keying off immutable digests and attestations rather than trusting tags or state files to stay accurate. The result is that when the next xz-utils-style backdoor or typosquatted dependency surfaces, the organization's first question isn't "how do we even find out where this is running" — it's already answered, and the team can move straight to containment.