Define applications by Code Criteria - Administrator Guide - Cortex Cloud Posture Management - Cortex CLOUD

Under Modules, select Application Security → Applications, then open the Application Criteria tab and select + Add Criteria.

Configure the General step.

1. Select Code as the Criteria type.

2. Provide a Criteria name (required) and description.

3. Click Next.

Configure the Define Criteria step.

The Define Criteria step determines how matching assets group into applications. These settings control whether an application is defined as a single repository or a broader organization, and how the system handles assets with identical names across your environment. Connected runtime and deployment assets are automatically linked to these boundaries to provide a complete view of the application lineage.

1. Select one or more VCS provider tiles to include in the Criteria: GitHub, GitLab, Bitbucket, Azure Repos, or AWS CodeCommit. Only providers with active integrations appear as selectable tiles.

2. Inside each selected provider tile, select a Group by level from the dropdown. The Group by level is configured per provider tile, so different providers in the same Criteria can use different grouping levels.

   • Organization: Group all repositories under the same VCS organization into one application

   • Project: Group all repositories under the same VCS project into one application

   • Repository: Create one application per repository

3. Merge organizations/projects/repositories with identical names (optional): The engine merges applications with the same name from the same VCS provider into one application .

   Example use case: Two projects in the same GitHub organization expose repositories with identical names that represent the same logical application. For a working example, refer to Example: Merge within a provider below.

   Tip

   Recommended: When creating your first Code Criteria, enable Merge organizations/projects/repositories with identical names unless you know that repositories with the same name across platforms must remain separate. When this toggle is off and the engine encounters identically named sources, every generated application name is automatically suffixed with the provider name (for example, payments-api_GitHub), and any remaining collisions receive an additional UTC timestamp suffix in the format MM_DD_YY_HH:MM:SS (for example, payments-api_GitHub_05_31_26_07:42:18). Warning: Because Criteria are immutable, consolidating these into one application later requires deleting and recreating the Criteria.

4. Unify applications across providers (optional): The engine merges applications with the same name from different VCS providers into one application. Available only when the Criteria targets more than one provider type; enabling it auto-enables and locks the first toggle.

   Example use case: The organization is migrating between VCS providers (for example, Bitbucket to GitHub) or runs the same application's source across multiple VCS systems. For a working example, refer to Example: Unify across providers

5. Click Next.

Configure the Scope step.

The Scope step defines which assets the Criteria evaluates. Use Scope filters to include or exclude specific organizations, projects, or repositories within each provider.

The Scope step displays one tab per selected provider tile from the Define Criteria step. Each tab is an independent filter expression for that provider. A tab left without filters includes every asset for that provider at the Group by level selected for that provider in the Define Criteria step.

Scope is dynamic. The engine re-evaluates filter matches on every refresh, so newly matching assets join automatically and assets that stop matching drop out.

How filters and tabs combine: Scope has three independent combination layers. The engine applies them in order: layer 1 inside each filter row, layer 2 across filter rows in the same tab, layer 3 across tabs.

For a worked walkthrough across multiple providers — including the case where one tab carries strict filters and another is left empty, refer to Example: Multi-provider scoping with filters.

1. Select the provider tab you want to filter.

   The tab name reflects the provider and its Group by level chosen in Step 2 (for example, GitHub — Repository). Repeat steps 4b-4d for each provider tab that requires filters. Tabs left without filters include all assets for that provider.

   Note

   A provider tab with no filters configured includes every asset for that provider at the chosen Group by level. Combined with the union behavior above, leaving multiple tabs unfiltered means the Criteria includes every connected asset across all selected providers , which is often the desired result for an organization-wide baseline Criteria, but can produce a large application count if used without intent. Use filters on tabs where the scope needs to be narrowed.

2. Select the filter field to narrow assets by:

   • Repository Name : Available at all Group by levels

   • Organization Name: Available when the tab's Group by level is Organization, Project, or Repository

   • Project Name: Available only when the provider supports projects (GitLab, Bitbucket, Azure Repos) and the tab's Group by level is Project or Repository

   Note

   Field availability is driven by the active tab's Group by level and provider capability. Fields that do not apply to the active tab are not displayed.

3. Choose an operator for the selected field: Equal, Not Equal, Contains, or Not Contains.

4. Enter one or more filter values.

   Multiple values within the same filter combine with OR logic; multiple filters across fields combine with AND logic.

5. Click Next.

For an example of Multi-provider scoping with filters, refer to Example: Multi-provider scoping with filters below.

Configure the Metadata step.

Configure rules to automatically assign ownership and risk levels to the generated applications.

1. Business Owner (required): Select the VCS hierarchy level from which to inherit ownership for every generated application. Options include None, Organization Owner, Project Owner, or Repository Owner (inherit the owner from the VCS repository).

2. Configure Business Criticality:

   1. Select a default severity level: Critical, High, Medium, Low.

   2. (Optional): Automatically upgrade criticality to Critical if a mapped asset is exposed to the internet: Enable this checkbox to elevate the criticality of internet-exposed assets to Critical, ensuring accurate risk prioritization.

   The business criticality level feeds the Urgency calculation for every issue associated with the generated applications.

3. Click Submit.

   Cortex Cloud will begin processing your criteria. Navigate to the Business Applications list to verify that your new applications have been generated and populated with assets.