> 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/unified-application-security-policies/core-concepts.md). # Core concepts This section defines the building blocks of a Unified Application Security Policy. All workflows, tenant (UI), API, CLI, and IDE, share these concepts **Policy types** Every policy belongs to one of three types. The policy type determines the available finding types, condition filters, and triggers | Policy type | Description | | -------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Code scanners** | Scans code for security issues throughout the development lifecycle. Covers code scanning (SAST, SCA (CVE vulnerabilities, license, package operational risk), IaC, Secrets) and image scanning (vulnerabilities, malware) across PR, periodic, and CI-triggered scans | | **CI/CD Configuration scanners** | Scans CI/CD and Version Control System (VCS) environments for insecure configurations. Restricts finding types to **CI/CD Risks** only and triggers to **Periodic** scan only | | **Drift Detection scanner** | Scans cloud environments to detect configuration drift between deployed resources and their IaC definitions. Restricts finding types to IaC Drift only and triggers to **Periodic** scan only | {% hint style="info" %} ### Note The Policy Type selection determines the available configuration options for conditions, filters, and triggers. {% endhint %} **Finding types** Each policy must include at least one finding type. These are narrowed down based on the policy type you select: * **Code scanners:** Includes Vulnerabilities, Secrets, IaC Misconfigurations, Code Weaknesses (SAST), License Issues, Operational Risks, and Malware * **CI/CD Configuration scanners:** Restricted to CI/CD Risks * **Drift Detection scanner:** Restricted to IaC Drift findings {% hint style="info" %} ### Note For a full description of each finding type and its applicability (Code vs. Image), refer to [Reference A: Finding type details](/application-security/application-security-posture-management-aspm/unified-application-security-policies/reference-a-finding-type-details.md). {% endhint %} **Condition filters** Filters allow you to narrow the scope of matched findings (e.g., by severity, CVSS score, or specific AppSec rules) * **Common filters:** All finding types support filters such as Severity and Backlog Status * **Type-specific filters:** Each finding type has unique filters such as fix availability or exploitability (EPSS/KEV) for Vulnerabilities, validity for Secrets, and compliance standards for IaC * **Logical groups (AND/OR):** Filters can be combined into groups where **AND** logic applies within a group and **OR** logic applies between multiple groups {% hint style="info" %} ### Note For a complete list of all available filters by category, as well as logical groups, refer to [Reference B: Condition filters and logic](/application-security/application-security-posture-management-aspm/unified-application-security-policies/reference-b-condition-filters-and-logic.md). {% endhint %} **Grace period (Vulnerabilities only)** You can define a remediation window (1–365 days) for vulnerability findings. During this window, any configured Block actions are suspended, allowing developers time to fix the issue without halting the pipeline. The Create Issue action continues to function normally so that the risk is tracked immediately. {% hint style="info" %} ### Note To understand the specific calculation logic and how grace periods align with your organization’s SLAs, refer to [Reference E: Grace period logic and configuration](/application-security/application-security-posture-management-aspm/unified-application-security-policies/reference-e-grace-period-logic-and-configuration.md). {% endhint %} **Scope** Scope defines the asset boundaries and the context in which the policy is evaluated. Implicit asset mapping: You do not manually choose a scope table. Instead, the selection of Policy Type automatically loads the underlying asset context: * **Code scanners**: Scope to code repositories and image registries * **CI/CD Configuration scanners**: Scope to CI/CD pipeline configurations * **Drift Detection scanner**: Scope to cloud assets and their associated IaC definitions The following configuration options are available within the policy wizard: * **Asset Groups:** Select one or more pre-configured asset groups to target specific repository collections. If none are selected, the policy applies globally to all assets within that policy type domain * **Applications:** Use Scope-Based Access Control (SBAC) to target specific applications for filtered evaluation, targeted visibility, and delegated enforcement per business unit * **Filtered evaluation**: Policies only evaluate findings from assets within the selected boundary; outside assets are excluded * **Targeted visibility**: Users see the Urgency distribution and findings only for their assigned application, not the entire organization * **Delegated enforcement**: Prevention policies scoped to an application boundary enforce only against assets within that boundary, enabling delegated shift-left enforcement per business unit

Note

Application scoping is currently not supported for Build Images

For a complete breakdown of which specific asset types can be filtered under each policy category, refer to [Reference C: Scope mapping details](/application-security/application-security-posture-management-aspm/unified-application-security-policies/reference-c-scope-mapping-details.md). **Triggers and actions** Triggers define when the policy evaluates findings, and actions define what happens when a match is found * **Proactive triggers**: PR scans and CI scans allow you to block merges or builds before they reach production * **Reactive triggers**: Periodic scans and Image Registry scans evaluate existing findings and create issues for remediation * **Actions**: Depending on the trigger, you can Block PR/CI, post a PR Comment, generate a CLI Report, or Create an Issue with an Override Severity setting * **Override issue severity**: When configuring the **Create Issue** action, the issue inherits the native severity of the finding. You can use the **Override Severity** option to force a specific severity level for that issue. Override Severity is available for all policy types.

Note

Images do not have a default severity. You must select a severity to continue when any image trigger is selected.

To see which actions are supported for each trigger, refer to [Reference D: Trigger and actions mapping](/application-security/application-security-posture-management-aspm/unified-application-security-policies/reference-d-trigger-and-actions-mapping.md). **Code to cloud context** Each trigger combination produces a different outcome in the code to cloud lifecycle: * **PR Scan + Block PR (proactive):** The vulnerability is blocked before merging into the protected branch. The vulnerability never reaches the protected branch, zero blast radius. No issue is created unless the **Create Issue** action is also enabled. Blocking a vulnerability at PR scan denies the attacker the deployed attack surface entirely * **CI Scan + Block CI (proactive):** The vulnerable artifact is blocked before deployment to prevent the vulnerability from reaching production * **Periodic Scan + Create Issue (reactive):** Issues are created and receive Urgency classification based on deployment context such as Internet Exposed or Business Criticality derived from code to cloud tracing. Prioritize remediation by Urgency level (Top Urgent first), not by severity alone. For more on Urgency refer to [Urgency](/application-security/application-security-posture-management-aspm/urgency.md) **Policy evaluation and urgency** Once a policy is triggered and an issue is created, the system determines its impact * **Unified evaluation:** The engine evaluates all findings against active policies and either deduplicates matches into a single centralized issue or creates individual issues per policy * **Urgency classification:** Resulting issues are automatically assigned an Urgency level based on dynamic code to cloud context to help prioritize remediation beyond static severity For the technical rules governing how multiple policy matches are handled, and the detailed calculation logic for Urgency scores, refer to [Reference F: Engine evaluation and Urgency logic](/application-security/application-security-posture-management-aspm/unified-application-security-policies/reference-f-engine-evaluation-and-urgency-logic.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/unified-application-security-policies/core-concepts.md?ask=&goal= ``` `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.