In April 2021, investigators discovered that Codecov's Bash Uploader script had been silently altered for roughly ten weeks, quietly exfiltrating environment variables — tokens, keys, and credentials — from thousands of customer CI pipelines. The script lived in source control. The stolen credentials unlocked production clouds. That gap, between a line of code and a live cloud environment, is exactly what "code to cloud security" is meant to close. Gartner popularized the umbrella term CNAPP (Cloud-Native Application Protection Platform) in its 2021 Market Guide to describe tooling that follows software from the first commit through the build pipeline and into runtime, rather than treating each stage as a separate product. Checkmarx, long known for SAST and SCA, has pushed into this territory too. Below, we unpack what code-to-cloud security actually requires, where point-in-time code scanners fall short, and how Safeguard approaches the problem differently.
What Is Code-to-Cloud Security?
Code-to-cloud security is the practice of tracing a single risk — a vulnerable dependency, a leaked secret, a misconfigured resource — across every stage it touches, from the developer's IDE through source control, CI/CD, artifact registries, and finally the running cloud workload. The idea, formalized by Gartner as CNAPP in 2021 and expanded in its 2023 Magic Quadrant coverage, is that a vulnerability's real risk can only be judged in context: a critical CVE in a container image that's never deployed to a reachable network path is a very different problem than the same CVE in an internet-facing production service holding an over-permissioned IAM role. Point tools that only see "code" or only see "cloud" can't make that call. A 2024 IBM Cost of a Data Breach report found breaches that took over 200 days to identify cost organizations $1.35 million more on average than those detected faster — and fragmented tooling with no cross-stage correlation is a major reason detection stalls.
Why Isn't Scanning Code Alone Enough Anymore?
Code scanning alone isn't enough because most real-world breaches originate in the gaps between tools, not inside any single scanner's report. The Log4Shell vulnerability (CVE-2021-44228), disclosed on December 10, 2021, was found by Google researchers to affect roughly 35,000 Java packages on Maven Central — but knowing a library was vulnerable told teams nothing about which of their running services actually loaded the flawed class at runtime, or which had public internet exposure. Similarly, the 2023 MOVEit mass breach (CVE-2023-34362), which Progress Software disclosed in May 2023, ultimately affected more than 2,700 organizations according to public breach trackers — a single SQL injection flaw in one product cascaded into cloud data exposure across banks, government agencies, and universities because nobody had a live map connecting that code path to the data it touched. SAST and SCA tools are excellent at finding flaws in source. They were never built to tell you whether that flaw is reachable, internet-facing, or sitting next to a cloud credential with admin rights.
How Does Checkmarx Approach Code-to-Cloud Coverage?
Checkmarx approaches this primarily by consolidating application-layer scanners — SAST, SCA, IaC scanning, API security, and container scanning — under the Checkmarx One platform, which it has expanded through acquisitions like Dustico and Merobase over the years to strengthen software composition analysis. That consolidation genuinely helps developers see more findings in one dashboard, and Checkmarx has invested in AI-assisted remediation suggestions inside the IDE and PR workflow. But the platform's center of gravity remains the code and pipeline layers: it was built outward from AppSec scanning rather than inward from live cloud telemetry. That means correlating a finding with actual runtime exposure — which workloads are internet-reachable, which service accounts are overprivileged, which secrets are actively used in production — typically requires stitching Checkmarx's output together with a separate CSPM or CWPP tool, re-introducing the very stage boundaries code-to-cloud security is supposed to eliminate.
What Breaks When Code, Pipeline, and Cloud Tools Don't Share Context?
What breaks is prioritization: teams end up fixing what's loudest in a dashboard instead of what's actually reachable by an attacker. A vulnerability scanner might surface 8,000 open findings in a mid-sized environment (a volume regularly reported by security teams using disconnected SAST/SCA/CSPM stacks), while fewer than 5% of those are typically both exploitable and internet-facing according to attack-surface studies from vendors like Rezilion and others analyzing real customer environments. Without shared context, triage becomes a full-time job of manual cross-referencing between a code scanner's ticket queue, a cloud posture tool's alert feed, and a runtime agent's log — and the mean time to remediate stretches accordingly. Verizon's 2024 Data Breach Investigations Report found that breaches involving a third party — including software supply chain components — nearly doubled year over year, reaching 15% of all breaches, which the report's authors attributed partly to the difficulty organizations have tracking dependencies once they leave the repository.
What Does a Real Code-to-Cloud Attack Path Look Like?
A real code-to-cloud attack path looks like the September 2022 Uber breach: an attacker purchased stolen employee credentials, defeated MFA fatigue, then found a PowerShell script on an internal network share containing hardcoded admin credentials for Uber's Thycotic privileged-access-management system — credentials that unlocked AWS, GCP, and internal tooling consoles. No single scanner "owns" that chain. It starts with a secret hardcoded in a script (a code-layer problem), sits dormant on an internal share (a pipeline/infrastructure visibility gap), and ends with full cloud administrative access (a runtime and identity problem). A comparable pattern appeared in the Toyota Motor Corporation incident disclosed in October 2022, where a GitHub access token was left exposed in a public repository for roughly five years, ultimately exposing source code and customer data tied to Toyota's T-Connect service. And in September 2025, security researchers tracked a self-propagating npm worm — nicknamed "Shai-Hulud" — that spread through compromised maintainer accounts, embedded itself in post-install scripts, and specifically hunted for CI/CD tokens and cloud provider credentials on infected build machines, automatically publishing malicious versions of any package it could reach. Each of these breaches began as a small, code-adjacent artifact and ended as a cloud compromise — precisely the path code-to-cloud tooling is designed to make visible before an attacker walks it.
How Is Code-to-Cloud Security Actually Measured or Validated?
It's measured by whether a security team can answer one question in minutes, not days: "if this specific finding were exploited right now, what could an attacker actually reach?" Mature CNAPP programs benchmark themselves against metrics like mean-time-to-remediate for internet-reachable criticals (industry conversations frequently cite a target under 24-48 hours for actively exploited, reachable vulnerabilities, versus SLAs of 30-90 days for routine findings) and the percentage of total findings that are automatically de-prioritized because they're unreachable or already mitigated by network controls. Organizations that build a real code-to-cloud graph — linking a repository, its build artifacts, its deployed workload, and that workload's cloud identity and network exposure — typically report cutting "true critical" ticket volume by an order of magnitude compared to raw scanner output, because context does the filtering that manual triage used to do.
How Safeguard Helps
Safeguard was built around the premise that a vulnerability, a leaked secret, or a malicious dependency is only as dangerous as the path it opens to your cloud environment — so we designed the platform to track that path natively instead of bolting cloud context on after the fact. Safeguard continuously scans source repositories, dependencies, and CI/CD pipeline configurations for vulnerable packages, hardcoded secrets, malicious or typosquatted packages, and misconfigured pipeline permissions, then correlates every finding with build provenance (in line with SLSA framework principles) so you know exactly which commit, which pipeline run, and which artifact introduced a given risk. From there, Safeguard maps deployed artifacts to their live cloud workloads and identities, so a finding in your repository is automatically enriched with runtime facts: is this service internet-facing, what IAM permissions does it actually hold, and is the vulnerable code path reachable at runtime. That end-to-end graph is what lets Safeguard collapse thousands of raw findings into a short, ranked list of issues that are both exploitable and reachable — the same kind of prioritization gap that let a hardcoded credential sit unnoticed until it became the pivot point in the Uber breach, or a single altered upload script quietly compromise thousands of pipelines at Codecov. Where a code-centric AppSec platform hands you a long backlog and a separate cloud tool hands you another, Safeguard hands your team one prioritized, cause-and-effect view of risk from the first commit to the running workload — so the gap that attackers keep exploiting stops being invisible.