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 |
Note
The Policy Type selection determines the available configuration options for conditions, filters, and triggers.
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
Note
For a full description of each finding type and its applicability (Code vs. Image), refer to Reference A: Finding type details.
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
Note
For a complete list of all available filters by category, as well as logical groups, refer to Reference B: Condition filters and logic.
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.
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.
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.
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.
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
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.