AppSec policies define threat responses by setting conditions, scope, and actions. Use out-of-the-box policies or clone them to create custom ones.
Unified Application Security Policies provide a centralized framework to consolidate code, build, and deploy security enforcement into a single policy definition. This allows organizations to manage risk end-to-end across the Software Development Life Cycle (SDLC) by unifying code-based scans, CI image scans, and image registry scans from both Application Security and Cloud Workload Protection (CWP) modules. Designed for pre-runtime security, the framework defines conditions, triggers, and actions for the policy engine to evaluate and execute. Runtime enforcement policies remain separate and are not governed by this framework.
Core Achievements
Shifting Enforcement Left: A single policy definition enforces prevention at PR, CI, and periodic stages, blocking vulnerabilities at the earliest possible point in the SDLC
Single policy definition: One policy governs code, build, and deploy enforcement, eliminating redundant configurations and ensuring consistent enforcement across stages
Unifying Image and Code policy management: A single policy definition governs code-based scans, CI image scans, and image registry scans and the image scanning capabilities of the Cloud Workload Protection module
Enabling grace periods: Vulnerability-specific grace periods prevent immediate blocking of builds while providing a defined remediation window based on fix or publish dates
Improving policy efficiency visibility: The policy side card displays real-time metrics for PR and CI blocks and hourly-updated issue counts, enabling data-driven policy optimization
Supporting multiple policy matching: A single finding can match multiple policies. For code findings, actions are deduplicated. For image findings, each matching policy evaluates its actions independently
Functional responsibilities
The Unified Policy framework facilitates a structured delegation model between Governance and Operations:
AppSec managers (Governance): Define prevention policies that specify which findings trigger enforcement actions across code, build, and deploy stages. Review policy efficiency metrics to optimize policy coverage and reduce noise
AppSec practitioners (Operations): Respond to policy-driven issues, remediate blocked PRs and CI pipelines, and manage the remediation lifecycle within SLA targets
Policy migration and backward compatibility
All existing AppSec and CWP policies are automatically migrated to the unified policy structure:
AppSec policies: Migrated with the new trigger and finding type format. New trigger types are added with default disabled values
CWP policies: Migrated from the CWP API to the unified policy storage. Both OOTB and custom CWP policies are included
Public API: The public API remains backward compatible. Existing API consumers continue to function without modification. The API returns additional fields for the new unified structure
Prerequisites
Before creating a Unified Application Security policy, verify the following:
Prerequisite | Description |
|---|---|
License |
|
RBAC role | The |
Connectivity and ingestion | At least one active primary data source (VCS integration or a connected third-party vendor where repositories are mapped to corresponding entities) Note: For third-party entities, generating and remediating issues is supported, but blocking actions are not supported |
Scanner configuration | Relevant scanners (SAST, SCA, IaC, Secrets, Malware) enabled for the target repositories. Not required when creating policies exclusively for ingested third-party scanner findings*. For Code Weakness (SAST) policies, configure a third-party SAST integration through a vendor (such as Snyk) or the generic third-party collector, as Cortex Cloud does not include a native scanner |
API Key | A valid Cortex Cloud API key with Note: The Console workflow authenticates through the browser session and does not require a separate API key |
Asset Groups (optional) | Pre-configured asset groups for scoping policies to specific repository collections |
Applications (optional) | Pre-configured applications for scoping policies to specific application boundaries |
Note: Third-party-only environments:
If your environment exclusively ingests third-party scanner data (without native Cortex scanners or VCS integrations), you can still create Unified Application Security Policies. The VCS integration and scanner configuration prerequisites above do not apply
The available trigger is Periodic Scan and the available action is Create Issue. Block PR and Block CI actions require PR Scan and CI Scan triggers, which depend on a native VCS integration and are therefore not available for third-party-only environments. Refer to Reference D: Trigger and actions mapping for details
Workflows overview
Unified Application Security policies can be managed and consumed through four workflow channels:
Tenant (UI) workflow: Full policy lifecycle management through the Cortex Cloud tenant (UI). Refer to Tenant (UI) workflow
API workflow: Programmatic policy management through the Cortex Cloud public API. Refer to API workflow
CLI workflow: Scan-time policy evaluation during CI code scans. Refer to Cortex CLI workflow
IDE workflow: Scan-time policy evaluation during local developer scans. Refer to IDE workflow
Terraform workflow: Manage Unified Application Security policies through Terraform to programmatically define finding types, evaluation conditions, and enforcement actions. Refer to Terraform workflow for policies
Each channel supports a different subset of capabilities as described in the table below.
Capability | Tenant (UI) | API | CLI | IDE | Terraform |
|---|---|---|---|---|---|
Create policies | ✓ | ✓ | ✗ | ✗ | ✓ |
Edit policies | ✓ | ✓ | ✗ | ✗ | ✓ |
Delete policies | ✓ | ✓ | ✗ | ✗ | ✓ |
Enable/disable policies | ✓ | ✓ | ✗ | ✗ | ✓ |
Duplicate policies | ✓ | ✓* | ✗ | ✗ | Via HCL copy*** |
View policy list | ✓ | ✓ | ✗ | ✗ | ✓ |
View policy details | ✓ | ✓ | ✗ | ✗ | ✓ |
View efficiency metrics | ✓ | ✓ | ✗ | ✗ | ✗ |
View policy-driven issues | ✓ | ✗ | ✗ | ✗ | ✗ |
Evaluate findings against policies | Automatic** | Automatic** | ✓ | ✓ | Automatic** |
Block PR/CI based on policy | Automatic** | Automatic** | ✓ | ✗ | Automatic** |
Display policy-matched findings | ✓ | ✗ | ✓ | ✓ | ✗ |
* API: No dedicated duplicate endpoint. Duplicate a policy by retrieving it (GET), modifying the name field, and creating a new policy (POST).
** The platform evaluates findings against policies automatically during periodic scans and blocks PRs/CI pipelines automatically during scan-triggered evaluations. These capabilities are not user-initiated actions in the Console, API or Terraform.
*** Duplicate policies via Terraform: While there is no explicit duplicate command, you can easily clone policies by copying the HCL resource blocks and updating the name attribute in your configuration files.