Ingest third-party data sources

Centralize findings from supported third-party or SARIF-compatible scanners into Cortex Cloud. Unified triage, Urgency-based priority, and policy enforcement in one view.

Cortex Cloud third-party ingestion centralizes security findings from external scanners into a unified data model. By normalizing data from supported vendors and SARIF-compatible tools, the platform provides a single interface for triage, Urgency-based prioritization, and Unified Application Security Policy enforcement. This ensures that external findings are treated with the same consistency and code-to-cloud traceability as native Cortex Cloud detections.

Use this integration to ingest supported data from supported vendors and custom data through the Generic 3rd Party AppSec Collector. Once ingested, these data/findings populate the standard Code Weaknesses and SCA CVE tables, allowing organizations to maintain global governance and remediate critical risks without switching between disparate vendor dashboards.

Third-party SCA ingestion covers CVE vulnerabilities only. The License Miscompliance and Package Operational Risk issue types are produced exclusively by the native Cortex Cloud SCA scanners and are out of scope for third-party ingestion, even when the source vendor emits license or operational-risk data in its native API.

Core achievements

• Unified policy governance: Ingested findings are evaluated against the same Unified Application Security Policies and Tenant Scope-Based Access Control (SBAC) as native scans
• Continuous backlog detection (pull-based): Native integrations with supported vendors surface findings that already exist in the codebase, feeding Urgency-based prioritization and SLA tracking
• Shift-left enforcement (push-based): Custom SAST scanner findings pushed via the Generic Collector during build runs can trigger PR comments, CI/CD policy evaluations, and build failures before deployment
• Single-pane triage: Consolidates findings into standard platform Code Weaknesses and Vulnerabilities tables, eliminating context-switching across disjointed vendor dashboards
• Code-to-Cloud traceability: Mapping third-party findings to repositories connects them to active production deployment context (such as running workload status and internet exposure) to power the Urgency engine

Prerequisites and governance

Roles and permissions

To manage the integration lifecycle—including adding instances, configuring repository scopes, rotating API keys, and managing webhook credentials—your account must possess the Data Sources View/Edit permission.

• RBAC role alignment: This permission is assigned by default to the Account Admin, Security Admin, Instance Administrator, and AppSec Admin built-in roles
• Data visibility scope: To view ingested findings, you must also hold the Application Security Issues View permission, and target repositories must lie within your SBAC Asset Group scope

Repository mapping requirements

• Active VCS: Before mapping any third-party project, application, or portfolio, the underlying Version Control System (VCS) repository must already be onboarded, connected, and active in Cortex Cloud
• Mapping uniqueness constraint: A single third-party project or application can only be mapped to one Cortex Cloud repository at a time. Only mapped projects are ingested

Supported third-party integrations

Cortex Cloud Application Security supports the following third party ingestions:

• Checkmarx One (SCA Vulnerabilities and SAST Code Weaknesses)
• Semgrep (SCA Vulnerabilities and SAST Code Weaknesses)
• Snyk (SCA Vulnerabilities and SAST Code Weaknesses)
• SonarQube / SonarCloud (SAST Code Weaknesses)
• Veracode (SAST Code Weaknesses from Periodic/CLI Scans)
• Generic 3rd Party AppSec Collector (SARIF v2.1.0 SAST findings pushed from CI/CD pipelines)

Post-onboarding navigation and operational workflows

Setting up the initial connection is only the first step. Once your third-party integrations are connected, the data and integration lifecycles split into two distinct operational flows: Administrative instance management and security posture governance (ASPM) .

Before you begin configuring your first integration, understand how these post-onboarding stages are mapped:

Integrations Lifecycle Administration & Automation

Use Third-party integrations lifecycle administration and automation to automate, manage integration instances and cleanup connectors:

• Administration channels matrix: The capabilities summary routing you to the Tenant UI, Public REST API, or Terraform Provider based on task
• Modify scope: How to edit active integrations to map newly created repositories or adjust ingested scanner types
• Key and token rotation: Step-by-step procedures for periodically updating your vendor API keys, tokens, or OAuth client secrets without disrupting scanning schedules
• Decommissioning and data retention: Crucial platform behavior tables explaining which integrations permanently purge their findings upon deletion (such as Semgrep, Checkmarx, SonarQube) versus those that preserve historical findings for audit integrity (Snyk)

Posture governance and security triage

Use Manage the third-party data lifecycle for understanding, investigating and remediating issues generated from ingested findings. Once connected, all raw findings are automatically normalized, prioritized, and subjected to active policy gates.

• Understand and manage SAST ingestion: Explains how to navigate the master Findings tab to investigate raw code weaknesses, filter by vendor data source (e.g., CHECKMARX, SEMGREP, SNYK), and identify scanner origins in the issue side panel:
• Understand and manage SCA ingestion: Explains how third-party package vulnerabilities are deduplicated and prioritized using real-world exploit intelligence and code-to-cloud deployment context (whether the package is active in a running workload), and details the CVE-only ingestion boundary: