How the C2C engine works

Cortex Cloud maps and maintains lineage using a specialized correlation engine. Full coverage is achieved when the system can resolve the chain: Repository → Pipeline → Image → (optional Registry) → Runtime resources.

The engine relies on three primary mechanisms:

• Asset Lineage graph: A queryable graph database populated by ingesting metadata from Version Control Systems (VCS), CI/CD pipelines, runtime scanners, and AI-powered analysis of build logs to extract deterministic links NOTE: For the complete list of supported providers and build tools per component (VCS, CI/CD, containers, VM images, IaC) that are required to build the asset lineage, refer to Reference A: Supported integrations and asset stages.
• Infrastructure-as-Code (IaC) Traceability (YOR): Cortex Cloud relies on YOR tags to bridge the gap between your static IaC templates (like Terraform or CloudFormation) and the dynamic, live cloud assets they create. During a scan, the Cortex Cloud tagging bot automatically applies a unique YOR trace tag to your IaC resources. Cortex Cloud uses these specific tags to build your Asset Lineage Graph, drawing a direct link from the source code template to the exact cloud asset it provisioned (IaC Resource → Cloud Asset). If YOR tags are missing, the lineage link breaks. To fix this, the system will prompt you to visit the YOR website to trigger the tagging process, ensuring you maintain full visibility into your infrastructure
• Drift detection logic: Correlates the declared state from VCS with the runtime state from CSPM integrations, using Git as the single source of truth. A runtime change is flagged as drift only when it violates a security policy that is not violated in the source code, a deliberate design choice that keeps the signal restricted to security-relevant regressions rather than every operational change made outside of Git