Code to Cloud context maps asset lineage across the SDLC. By connecting repos, pipelines, and infra, it provides end-to-end traceability from code to runtime.
Code to Cloud context is the correlation engine that maps and maintains the full lineage of assets across the SDLC. By connecting repositories, pipelines, and infrastructure, it provides end-to-end traceability from source code to runtime resources.
Full Code to Cloud (C2C) coverage is achieved when Cortex Cloud can resolve the following chain: Repository → Pipeline → Image → (optional Registry) → Runtime resources (including VMs, VM images, and IaC-defined infrastructure). This lineage mapping connects repositories, pipelines, images, VMs, VM images, IaC-defined infrastructure, and runtime assets back to their originating code, pipelines, IaC resources, and OSS packages, providing full lifecycle context rather than isolated runtime visibility.
When relationships cannot be resolved, for example, due to missing YOR tags or pipeline integrations, Cortex Cloud detects coverage gaps and provides specific configuration steps to fix them. If any part of this chain is unsupported or disconnected, the tenant provides only a partial view, isolating code-side or cloud-side components without end-to-end links. This limits bidirectional impact analysis: code issues cannot be traced to runtime for prioritization by actual exposure, and vulnerabilities cannot be traced back to their source code or owner.
By establishing deterministic links between code, build artifacts, and runtime infrastructure, Code to Cloud context enables the following:
Bidirectional traceability: Trace runtime issues back to the specific line of code, developer, or pipeline that introduced them
Contextual application grouping: Automatically groups related assets into business applications, allowing you to manage risk based on actual business impact
Precision prioritization: Prioritize remediation based on actual exposure, such as whether a vulnerability is active or internet-facing, and its potential business impact
Drift detection: Compare the intended state defined in Infrastructure-as-Code (IaC) templates against the actual state of runtime resources to identify unmanaged changes
For IaC drift detection policies: To configure the security baselines and specific rule mappings that drive this detection logic, see Create IaC Drift Detection policies
For IaC Drift Detection issues: To investigate, prioritize, and remediate the specific runtime discrepancies identified by these scans, see IaC Drift Detection scans
Core components and mechanisms
Asset Lineage Graph: This queryable graph database automatically maps the relationships between upstream assets (code repos, packages, IaC resources) and downstream assets (container images, virtual machines, runtime workloads, and cloud services). It is populated by ingesting metadata from:
VCS and CI/CD: Captures repository metadata, build logs, and pipeline run data
Build artifacts: Extracts deterministic links (such as container image digests and VM image references) from container and VM image builds. To ensure comprehensive coverage when standard static detection patterns do not match, Cortex Cloud utilizes AI-powered analysis of CI/CD build logs to automatically detect these links
Runtime scanners: Maps running workloads back to their build sources via the Cloud or Kubernetes connectors
Infrastructure-as-Code (IaC) Traceability (
YOR): To bridge the gap between static IaC files and dynamic cloud resources, Cortex Cloud leveragesYORtags:Automated mapping:
YORapplies unique trace tags to IaC resources. Cortex Cloud uses these tags to link a Terraform or CloudFormation template to the specific cloud asset it provisioned (for example, IaC Resource → Cloud Asset)Gap analysis: If YOR tags are missing, the Asset Lineage Graph cannot complete the link. The system will prompt you to initiate tagging via the yor website to unlock full visibility
Drift detection logic: Code to Cloud enables drift detection by treating Git as the single source of truth. The system correlates the declared state (from VCS) with the runtime state (from CSPM integrations). Drift is only flagged when a runtime change violates a security policy that is not violated in the source code, ensuring focus on security-relevant regressions rather than operational noise