> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/application-security/application-security-posture-management-aspm/manage-the-third-party-data-lifecycle.md).

# Manage the third-party data lifecycle

After you [Ingest third-party data sources](/application-security/application-security/onboard-data-sources/ingest-third-party-data-sources.md), 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:

```
+--------------------------------------------------------------------------+
|                       URGENCY PRIORITIZATION ENGINE                      |
+--------------------------------------------------------------------------+
|  1. EXPLOIT INTEL           |  2. DEPLOYMENT CONTEXT | 3. BUSINESS CONTEXT |
|  - CVSS Severity            |  - Active in Runtime   | - App Criticality   |
|  - EPSS Exploit Probability |  - Internet Exposed    | - Mapped Business   |
|  - CISA KEV Exploitation    |  - Accessing DBs       |   Application       |
+--------------------------------------------------------------------------+
```

* **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](/application-security/application-security-posture-management-aspm/urgency.md).

### 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](https://notebook.google.com/manage-integration-instances.md).

### 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

* For more information about managing SAST issues, refer to [Manage SAST code weakness issues](/application-security/application-security-posture-management-aspm/manage-code-weakness-issues.md)
* For more information about managing SCA CVE issues, refer to [Software Composition Analysis (SCA) vulnerability issues](/application-security/code-security/code-security-scanners/software-composition-analysis-sca-scanners/software-composition-analysis-sca-vulnerability-issues.md)
* For policy configuration and enforcement, refer to [Unified Application Security policies](/application-security/application-security-posture-management-aspm/unified-application-security-policies.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://cortex-docs.paloaltonetworks.com/application-security/application-security-posture-management-aspm/manage-the-third-party-data-lifecycle.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.