Ctrlk
BlogSupport
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Manage the third-party data lifecycle

After you Ingest third-party data sources, Cortex Cloud ingests its security findings. It applies the same governance, prioritization, and policy workflows used for native scans.

This section explains how to investigate SAST and SCA findings, prioritize issues, remediate them, and enforce unified policies.

The lifecycle is: Investigate (Findings) → Prioritize (Issues/Urgency) → Remediate (Cases/Fix Verification) → Enforce (Policy Gates).

Phase 1: Investigate and understand ingested findings

Before any risk can be remediated, security teams must understand the raw security telemetry flowing into the tenant. This investigation is performed at the Finding level.

Finding vs. issue: the core operational distinction

Cortex Cloud enforces a strict data separation between raw scanner outputs and actionable work items:

  • Finding (the raw telemetry): A finding is an individual, raw detection reported by an underlying scanner (such as a specific line-of-code defect or a vulnerable package in a repository). Findings are non-actionable, raw database records used for audit and granular investigation

  • Issue (the actionable unit): An issue is a consolidated, deduplicated, and tracked record generated only when a raw finding matches a Unified Application Security Policy. For example, if Snyk detects the same CVE across ten different scanned branches or periodic scans, Cortex Cloud ingests ten findings but consolidates them into a single, tracked issue to eliminate remediation noise

The findings inventory table

To analyze raw, unconsolidated third-party scan results, practitioners utilize the Findings Inventory. This view is identical for both SAST (Code Weaknesses) and SCA (Vulnerabilities):

  1. Navigate to the central module view:

    • For SAST: Go to Modules → Application Security → Code Weaknesses

    • For SCA: Go to Modules → Application Security → Vulnerabilities

  2. Switch from the default Issues tab to the Findings tab at the top of the workspace.

  3. Filter by data source: Filter the Data Source column using the normalized vendor values:

    • CHECKMARX (Checkmarx One)

    • SEMGREP (Semgrep)

    • SNYK (Snyk Code / Open Source)

    • VERACODE (Veracode)

    • SONARQUBE (SonarQube Server / SonarCloud)

    • COLLECTOR (Custom SARIF tools uploaded via the Generic 3rd Party AppSec Collector)

  4. Filter by scanner (contains match): For granular isolation of specific third-party scanning engines, apply a filter on the Scanner column using a Contains expression with the vendor name (e.g., Scanner Contains Snyk or Scanner Contains Semgrep). This is highly useful when managing multiple third-party SCA instances mapping to the same software package assets.

  5. Granular diagnostics: Select any row in the table to slide open the detail card. This side panel displays the raw findings metadata, including exact line-level traceability, source files, rule IDs, and raw severity tags mapped directly from the third-party tool.

Phase 2: Prioritize actionable issues

Remediate Issues, not raw findings. Policies create issues from findings and assign Urgency based on runtime exposure, business impact, and protection status. Address Top Urgent and Urgent issues first to reduce immediate risk.

The Urgency engine applies the same context-aware scoring to both ingested SAST and SCA issues using three unified dimensions:

  • Exploit Intelligence: Ingested findings are enriched with CVSS severity, exploit probability (EPSS scores), and the CISA Known Exploited Vulnerabilities (KEV) catalog to determine if the vulnerability is actively being exploited in the wild

  • Code-to-cloud deployment context (lineage graph): The engine traces the Code-to-Cloud (C2C) lineage of the mapped repository. If the container image or artifact built from the repository where Snyk or Checkmarx detected the issue is currently Active in a Running Workload, Internet Exposed, or Accessing Sensitive Databases in production, its Urgency is elevated to Top Urgent or Urgent. If the code is not deployed, it is downgraded

  • Business Application Criticality: Issues inherit the business criticality (Critical, High, Medium, Low) of their parent Business Application mapped via code or cloud Criteria. This ensures a SAST weakness on an internal tool is triaged below the same weakness on a core payment gateway

For more information, refer to Urgency.

Phase 3: Remediate issues

Once prioritized, remediation of third-party issues follows a unified, standardized lifecycle.

Remediation workflows

  1. Triage by repository and application:

    • Navigate to the AppSec Coverage page.

    • Filter by the vendor column (e.g., is_scanned_by_snyk=true or is_scanned_by_checkmarx=true) to identify active coverage.

    • Select the target repository and click Issues to jump to the platform Issues page, which automatically pre-filters the view to display only Snyk-originated or Checkmarx-originated issues.

  2. Case consolidation: Security managers group related, actionable issues into Cases. Grouping can be done by repository owner, vulnerability type, or microservice boundary.

  3. Remediation action:

    • Open the issue side card to view standard, step-by-step remediation instructions mapped for third-party findings.

    • Assign the issue or Case directly to the repository owner identified via VCS metadata.

    • Developers apply the code fix or upgrade package dependencies in their IDE or local workspace.

Fix validation and synchronization

  • Once a developer commits a fix and runs a new scan (or Snyk/Semgrep completes its next scheduled scan), the updated findings are ingested.

  • Cortex Cloud's background synchronization detects that the finding is no longer reported in the latest completed scan.

  • The corresponding tracked Issue is automatically marked as Resolved in the Cortex Cloud tenant on the next polling cycle, resetting coverage status and dashboard metrics.

[!NOTE] Integration instance decommissioning and data retention: When an integration instance is deleted, the system handles previously ingested findings and issues based on vendor-specific compliance rules (for example, Snyk retains findings for historical audits, while Checkmarx purges all data upon deletion).

For the complete, detailed Data Retention & Deletion Cleanup Matrix covering all six third-party integrations, refer directly to the master administration guide: Manage Integration Instances and Deletion Cleanup.

Phase 4: Enforce policies and shift-left

The ultimate goal of third-party ingestion is to transition from reactive detection to proactive, automated prevention. This is achieved using Unified Application Security Policies evaluated across three distinct triggers:

Trigger stage
Trigger type
Action and operational impact
Ingestion compatibility

Shift-left (PR)

PR Scan

Evaluates webhook-delivered code changes on pull requests. Generates automated PR Comments with remediation steps directly inside GitHub/GitLab

Supported natively for Snyk and Semgrep. Not supported for Veracode

Shift-left (CI/CD)

CI Scan / Build Scan

Real-time evaluations embedded in build lines. If a scan payload (pushed via Generic Collector) violates a policy, it triggers exit-code failures that block the build or PR merge

Supported for all tools pushing SARIF payloads via the 3rd Party AppSec Collector

Continuous (backlog)

Periodic Scan

Runs on a daily or scheduled basis against the main repository branch. Violations automatically create a tracked Issue in the tenant, assign ownership, and initiate SLA tracking

Supported for all third-party integrations (Snyk, Semgrep, Checkmarx, SonarQube, Veracode, and Generic Collectors)

Learn more

PreviousCode weakness findings
NextSoftware Supply Chain Security

Last updated

Was this helpful?