Code Security

Confidential - Copyright © Palo Alto Networks

Confidential - Copyright © Palo Alto Networks

1. Code Security

2. Code Security user roles and permissions

3. Code Security assets

4. Software packages as assets

4.1. In-depth software package asset information

5. Infrastructure-as-Code (IaC) resources as assets

5.1. Explore IaC assets

5.2. In-depth IaC resource asset information

6. Code Security scanners

7. Secrets scanners
7.1. Secretsissues

7.2. Secrets issues inventory

7.3. Detailed Secrets issue information

7.4. Secrets findings

7.5. Manage Secrets issues

8. Infrastructure as Code (IaC) scanners

8.1. Supported frameworks and languages

8.2. IaC misconfiguration issues

8.3. IaC misconfiguration issues inventory

8.4. Detailed IaC issue information

8.5. IaC misconfiguration findings

8.6. Manage IaC misconfiguration issues

9. Software Composition Analysis (SCA ) scanners

9.1. Supported Software Composition Analysis (SCA) frameworks and languages

9.2. Software Composition Analysis (SCA) vulnerability issues

9.2.1. Vulnerability issues inventory
9.2.2. Detailed vulnerability issue information
9.2.3. CVE vulnerabilities findings
9.2.4. Manage SCA CVE vulnerability issues

9.3. License miscompliance issues

9.3.1. License miscompliance issues inventory
9.3.2. Expanded License miscompliance issues information
9.3.3. License miscompliance findings
 9.3.4. Open-source software license categories
9.3.5. Manage license miscompliance issues

9.4. Package Integrity

9.4.1. Package Integrity inventory
9.4.2. Expanded Package Integrity issues inventory information
9.4.3. Package Integrity findings
9.4.4. Manage Package Integrity issues

10. Application Security scans management

10.1. Overview

10.2. Branch periodic scans

10.3. Pull Request scans

10.4. CI scans

10.5. Manage repository scan configurations

10.6. Monitor data source instances health

11. Application Security Policies

11.1. User roles and permissions

11.2. Policies inventory

11.3. Create Cortex Cloud Application Security policies

11.3.1. Create code security policies
[Link]. Cortex Cloud Application Security code policy Condition attributes

11.3.2. Create CI/CD configuration policies

[Link]. Cortex Cloud Application Security CI/CD policy Condition attributes

11.4. Manage Cortex Cloud Application Security policies

12. Application Security Rules

12.1. Roles and permissions

12.2. Rules inventory

12.3. Create custom Cortex Cloud Application Security rules

12.4. Manage Cortex Cloud Application Security custom rules

12.5. Configure YAML file properties

13. Application Security CLI

13.1. Connect Cortex CLI

13.2. Cortex CLI usage for Cortex Cloud Application Security

13.3. Cortex CLI Cortex Cloud Application Security command line reference

13.4. Cortex CLI common command line reference guide

13.5. Git Hooks

13.5.1. Cortex CLI pre-commit hooks
[Link]. Pre-commit hook usage

13.5.2. Cortex CLI pre-receive hooks

[Link]. Pre-receive hook usage
14. IDE
14.1. System requirements

14.2. Visual Studio (VS) Code and VS Code compatible IDEs

14.2.1. How to use the Cortex Cloud extension in VS Code

14.3. JetBrains
14.3.1. How to use the JetBrains Cortex Cloud extension
1 | Code Security
Code Security
Copyright ©

Abstract

Code Security identifies and mitigates vulnerabilities, secrets, and IaC misconfigurations, shifting security left
to protect data and maintain trust.

Code Security provides automated, native scanning tools designed to enhance the security posture of your
applications and infrastructure. Integrating these scanners into your development workflow facilitates a shift-
left approach to security, enabling the proactive identification and remediation of security issues early in your
software development lifecycle (SDLC), preventing them from reaching production environments.

Findings generated by native scanners are evaluated and elevated to actionable issues based on policies
defined within Cortex Cloud. Code Security issues are displayed in dedicated issue tables, organized by the
native Code Security scanner type (Secrets, SCA and IaC misconfigurations), providing security teams with
focused, manageable views, in specialized issue tables.

These tables are filtered instances of the centralized Issues table located under Cases & Issues. These
specialized Code Security issue tables only display issues generated from findings detected during periodic
scans. In contrast, the comprehensive Issues table includes all issues, regardless of their detection source,
such as periodic, pull request (PR), and continuous integration (CI) scans.

Code Security use cases

Prevent production incidents: By integrating security scans into CI/CD pipelines, organizations can block
insecure code from being merged into production, preventing critical vulnerabilities from reaching live
environments

Ensure compliance and reduce risk: Automated scanning for known vulnerabilities (CVEs) and open-
source license risks helps organizations adhere to regulatory requirements and minimize legal and
compliance exposure

Improve developer efficiency and productivity: Providing immediate feedback on security issues directly
within the IDE allows developers to fix problems as they code, reducing rework and accelerating secure
development

Gain comprehensive visibility into software assets: Building a complete inventory of open-source
packages and assessing your operational risk to help understand your software supply chain and
proactively manage potential threats from outdated or abandoned components

Streamline security operations: Centralized scan management, customizable policies, and API
integrations enable security teams to automate workflows, enforce security standards, and gain a
holistic view of your Application Security posture

Enhance traceability and remediation: Mapping security rules from code to cloud environments allows
for end-to-end traceability of issues, accelerating the identification of root causes and prioritization of
remediation efforts
Code Security key features

Comprehensive code scanning:

Software Composition Analysis (SCA):

Vulnerability scanning: Identifies known vulnerabilities (CVEs) in open-source dependencies

License scanning: Manages open-source license obligations and identifies compliance risks

Package Operational Risk scanning: Assesses the popularity, maintenance status, and
potential long-term risks of open-source packages (such as deprecation, maintainer
activity)

Secrets scanning: Detects hardcoded credentials, API keys, and other sensitive information within
source code

Infrastructure as Code (IaC) scanning: Identifies misconfigurations and security flaws in IaC
templates (such as Terraform, CloudFormation)

Seamless integration and shift-left capabilities:

Version control system (VCS) and CI tool onboarding: Integrates with popular VCS (such as
GitHub, GitLab, Bitbucket) and CI tools (such as Jenkins or GitHub Actions) for automated
scanning

CLI scans

Integration with CI tools: Allows for easy implementation in CI pipelines by adding a snippet,
enabling blocking of pipelines based on security policies

Dedicated Application Security CLI module (as part of Cortex Cloud unified CLI (which
includes Image, API, and code scanning)), enabling local scans or pipeline steps to detect
IaC, secrets, vulnerabilities, license, and package integrity findings

IDE support (JetBrains, VS Code): Plugins for popular Integrated Development

Environments (IDEs) to enable shift-left security, allowing developers to detect and fix issues
(IaC, Secrets, CVE, License, Package Integrity (Operational Risk)) directly as they write
code, including local fixes and suppression options

Centralized scan management:

Review of all scan types: Provides a unified view for periodic, Pull Request (PR), and Continuous
Integration (CI) scans

Detailed scan insights: Overview tabs for scan details and health, along with dedicated tabs for
each finding type (Vulnerabilities, Configurations, Secrets, Package Integrity)

Issue/Finding card access: Allows you to drill down into individual issues from the scan
management page

Reporting and blocking: Configurable policies to report findings or block pipelines based on
predefined Application Security policies

Out-of-the-box and customizable rules and policies:

 Out-of-the-box rules and policies, as well as the ability for custom creation

Customization of conditions and scope for pipeline blocking

Custom code to cloud rules mapping: Provides the ability to map custom Application Security IaC
rules to custom runtime CSPM (Cloud Security Posture Management) rules, improving issue
traceability and accelerating remediation by linking code-level issues to cloud runtime anomalies

Secure communication and APIs:

Transporter: A secure communication channel between your SDLC environment and Cortex Cloud

Application Security APIs: Public APIs for scan management, policies, and applications, enabling
enhanced automation, integration capabilities, and granular control with enforced user
permissions

2 | Code Security user roles and permissions

Cortex Cloud offers dedicated predefined user roles for Code Security: AppSec Admin, DevSecOps and
Developer, each with specific areas of responsibilities. When assigning roles to users, it's recommended to
align them with the user's required responsibilities within the application security framework.

The AppSec Admin has full permissions for all Cortex Cloud Application Security-related activities. They can
create and modify detection rules within the Code/Build domain, track progress, and adjust enforcements as
needed. Additionally, they can triage and investigate findings, issues, and cases spanning from code to cloud.
The role also includes complete visibility into all cloud assets.

The DevSecOps role is specifically designed as an intermediary, possessing more permissions than a
Developer but fewer than an AppSec Admin. This role actively manages security processes and tools to
embed security directly into development and operations workflows. Responsibilities include managing and
resolving security issues, performing scan management, and improving the overall application security
posture by integrating security practices throughout the development and operations lifecycle.

Developers within the Code Security environment have limited permissions primarily focused on viewing and
monitoring security information. They can access and analyze scan results, track progress, and collaborate
with security teams. However, they typically do not have the authority to modify detection rules, enforcements,
or directly address security issues.

Permissions defined in the predefined roles cannot be changed. However, you can save a predefined role as
a new custom role. This custom role can then be edited to meet specific organizational needs, offering a
balance between standardized roles and customizable access control.

Dedicated Code Security roles include permissions that extend beyond Code Security itself. In addition to
these dedicated users, other roles within your tenant are also granted specific permissions to Code Security.
You can view all permissions granted to user roles in your tenant by navigating to Settings → Configurations
→ Roles → select a role.

3 | Code Security assets

Code Security provides a comprehensive view of assets detected by native Infrastructure-as-Code (IaC) and
Software Composition Analysis (SCA) scanners. These assets are displayed in dedicated IaC Resources and
Software Package inventories. Both are specialized, filtered views within the broader All Assets inventory. This
focused approach allows you to manage and analyze your Code Security assets separately from other types
in your environment.

Code Security assets are a part of the broader Cortex Cloud Application Security asset suite, including:

ASPM assets, which include Repositories. For more information about Repositories, refer to Repositories
as assets.

CI/CD Security assets, which include VCS Organizations, CI/CD Instances and CI/CD Pipelines. For
more information about CI/CD Security assets, refer to CI/CD assets.

Identity assets, which include Collaborators. For more information about Collaborators as assets, refer to
VCS Collaborators-as-assets.

Code Security asset use cases

Visibility and context

Asset inventory: Maintain a comprehensive inventory of all detected assets, including their
metadata and relationships to other assets. This provides a centralized view of all components
within the environment

Code to cloud mapping: A graphical representation of the SDLC, highlighting the asset's location
within. This visualization allows for a clear understanding of the asset's journey and its relationship
to other components

Application path to production: Trace the asset's path through the application lifecycle, from its
origin in code repositories to its deployment. This includes identifying all intermediate stages and
dependencies

Security risks

Infrastructure as Code (IaC) misconfigurations: Identify misconfigurations associated with the IaC
asset configuration, and provide details such as severity, location, when created and the assignee

SCA CVE vulnerabilities: Identify known vulnerabilities in open-source packages associated with
an asset, including details such as severity, the CVE issue, CVSS score, when discovered and the
assignee

License miscompliance: Identify and detail license miscompliance issues within packages
associated with an asset, including severity, license category (such as strong copyleft), location,
when discovered, and the assignee

Package Integrity: Identify and detail any package operational issues in packages associated with
the asset, including severity, location, when created and the assignee

4 | Software packages as assets

The Software Packages asset inventory provides a centralized view of all open source software packages and
their details across your environments. The platform enables efficient tracking and management of your
software package assets, ensuring compliance with security and governance standards. You can directly
access package vulnerabilities, operational risks and license misconfiguration cases, issues, and findings
within the Software Packages asset inventory, allowing you to prioritize and remediate them without having to
navigate to a separate remediation section.

4.1 | In-depth software package asset information

Click an asset in the inventory table to open its side card, providing in-depth information organized into
several tabs. The Overview tab (default display) offers highlights and a general summary. Additional
contextual tabs provide specific details, including a Code to Cloud tab (providing context on the asset's path
to production), an Applications tab (displaying the applications in which the asset is detected), and tabs such
as Configurations and Code (focusing on specific issue types detected within the asset).

Software package summary

The software package asset summary, displayed at the top of the card, provides concise details about the
asset's key attributes, including the package name and originating package manager.

Overview

The Overview tab summarizes software package package highlights and properties.

Highlights include:

Critical/High issues: An aggregation of critical and high vulnerability issues associated with the package

New: Indicates whether the package was first detected in your environment during the past 30 days

Root: Indicates whether this package is the top-level package within its dependency tree, meaning it is
not a dependency of any other package within the project

Deprecated: Whether the package was officially deprecated by its maintainers. This indicates that it is
no longer recommended for use and could potentially include security risks

Risk summary: The amount of vulnerabilities associated with the package grouped by category (cases,
issues and findings) and their severity. For more information about OSS package vulnerabilities, refer to
Overview

Visibility timeline: When the package vulnerabilities were first and last detected

Properties:
 Asset details, including Asset Id, Asset Types and Asset Groups associated with the package

Applications: Lists the applications that include this package as part of their defined assets or
configurations. See Application below for more details

Package source: Includes details about the package origin, including its provider (such as PyPI, npm),
the repository and branch hosting the package source code, the path to its primary file, the license
under which it's distributed, its dependency type (direct or transitive), and a list of contributors

Scan information: A list of Software Composition Analysis (SCA) scans conducted on the package. Scan
details include the name of the scanner used, the specific branch of the package that was scanned, the
timestamp of the last scan, and the overall status of the scan (such as completed or failed).

For more information about scan management, refer to Overview.

The Highlights section and other asset properties only display attributes when their corresponding indicators
are present. For example, if an asset is not deployed, its deployment-related attributes will not show up;
similarly, if there are no detected issues, those highlights or properties will not appear.

Code

The Code tab identifies the package's location within your codebase by providing the repository, file path, and
specific line number. Additionally, it presents the package's dependency tree, viewable as either a graph or a
hierarchical list, presenting its relationships with other components.

Code to Cloud

The Code to Cloud tab visually represents the software development lifecycle (SDLC), focusing on the
package's role in the path to production. The graph describes the links between the repository node hosting
the package, the pipeline, image, and cluster.

Example SLDC workflow:

Developers write code and commit changes to a version control system like Git, storing it in a central
code repository

When code changes are pushed to the repository, an automated pipeline is triggered, handling build,
automated testing, and packaging code into a deployable artifact

The built and tested application is packaged into a container image, which is then pushed to a container
registry like Docker Hub or a cloud-specific registry

The container image is pulled from the registry and deployed to a container orchestration platform like
Kubernetes, managing running application instances (containers) for scalability, availability, and
resource management

The container orchestration platform runs on top of your chosen cloud infrastructure, such as AWS,
Azure, or GCP

Applications

The Applications tab provides an overview of the application associated with this package, including a
graphical representation of its path to production, which incorporates the package's role within the workflow.

For more information about applications, refer to Business application assets.

Vulnerabilities

The Vulnerabilities tab provides a list of vulnerabilities identified within the package in your environment. Each
vulnerability includes details regarding its severity level, associated CVE identifier, CVSS score, initial detection
date, and assigned team member or group responsible for remediation.

The table includes the following properties:

Severity level (icon): Indicates the level of severity of the vulnerability

Issue Name: The CVE identifier

CVSS Score: The Common Vulnerability Scoring System score that quantifies the severity of the
vulnerability

Assigned To: The person or team responsible for addressing the vulnerability

Creation Date: The date when the vulnerability was detected

For more information about SCA vulnerabilities, Software Composition Analysis (SCA) vulnerability issues

Package Integrity

The Package Inventory tab provides details about the popularity and maintenance of packages identified
within your SDLC. It also includes an inventory of package operational risk issues and package license issues,
offering a comprehensive view of the package's overall health and compliance.

The table includes the following properties:

Severity level (icon): Indicates the level of severity of the package license miscompliance

Issue Name: The package license miscompliance identifier

License Name: The name of the license associated with the package. This indicates the specific license
agreement that is potentially being violated

Asset Name: The name of the asset that uses the package with the license miscompliance. This
identifies where the license issue occurs

Branch: The branch of the codebase where the asset with the license issue is located

The Operational Risk Issues table includes the following properties:

Severity: Indicates the level of severity of the package operational risk

Issue Name: The package operational risk identifier

Asset Name: The name of the asset that uses the package with the package operational risk

Branch: The branch of the codebase where the asset with the package operational risk is located

Assigned To: The person or team responsible for addressing the package operational risk

Creation Date: The date when the package operational risk was initially detected

For more information on Package Operational Risks, refer to Package Integrity.

5 | Infrastructure-as-Code (IaC) resources as assets
The IaC resource asset inventory provides a centralized view of all infrastructure-as-code (IaC) resources and
their details across your environments. The platform enables efficient tracking and management of your IaC
resources, ensuring compliance with security and governance standards. You can directly access IaC
misconfiguration issues and findings within the IaC assets inventory, allowing you to prioritize and remediate
them without having to navigate to a separate remediation section.

5.1 | Explore IaC assets

To access IaC assets, under Inventory, select All Assets → Code → IaC Resources.

The IaC Resources assets page includes a dashboard and an inventory.

IaC resources dashboard

The dashboard includes two widgets:

Cloud Providers: Displays connected cloud providers (such as AWS and GCP) and the number of IaC
resources found in each provider

Frameworks: Displays connected frameworks (such as Terraform and Kubernetes) and the number of
IaC resources found in each framework

Selecting an item in either widget filters the table accordingly.

IaC resource asset inventory

The following table describes selected IaC resource properties of the inventory.

Property Description

Asset ID The identifier assigned to the IaC resource

Provider The version control system containing the IaC resource

Name The unique identifier for the IaC resource within the system

Resource Type The type of configurations or artifacts represented in the Infrastructure as

Code (IaC) assets, such as Dockerfile, AWS Internet Gateway and AWS
EKS Addon

Type The classification of artifacts or resources within IaC assets, such as

Dockerfile resource and Terraform resource
 Property Description

Cloud Provider The cloud provider where this IaC resource is deployed, such as AWS,
Azure, or GCP

Repository The version control system repository where the IaC code for this
resource is stored

File Path The relative path to the IaC provider file within the repository that defines
this resource

End Line The line number indicating the conclusion or endpoint of the
configuration code for a particular IaC resource within the specified file.
Example: for /[Link] (62-66), the end line refers to line 66, marking
the conclusion of the configuration related to the IaC resource defined in
the '[Link]' Terraform file

Framework The IaC framework used to define and manage this resource, such as
Terraform or CloudFormation

Branch The specific branch of the repository where the IaC asset is located

First Observed The date and time when this IaC resource was first discovered by the
system.

Type Category Fixed value: IaC Resource

5.2 | In-depth IaC resource asset information

Click an asset in the inventory table to open its side card, providing in-depth information organized into
several tabs. The Overview tab (default display) offers highlights and a general summary. Additional
contextual tabs provide specific details, including a Code to Cloud tab (providing context on the asset's path
to production), an Applications tab (displaying the applications in which the asset is detected), and tabs such
as Configurations and Code (focusing on specific issue types detected within the asset).
IaC resource summary

The IaC resource asset summary, displayed at the top of the card, provides concise details about the IaC
resource, such as its name (such as aws_s3_bucket.website), type (such as S3 bucket), and the associated
framework (such as Terraform).

Overview

The Overview tab summarizes IaC resource highlights and properties.

Highlights provide key security and operational insights related to the asset:

Critical/High issues: An aggregation of critical and high issues associated with the IaC resource

Internet Exposed Runtime Asset: Indicates whether the IaC resource, when deployed, results in a
runtime asset (such as a container), that is directly accessible from the public internet

Deployed: Indicates whether the IaC resource has been deployed and is currently active within your
cloud environment or infrastructure

New: Indicates whether the IaC resource was created during the past 30 days

Sensitive Data in Runtime: Indicates whether the IaC resource, when deployed, handles or stores
sensitive data within its runtime environment

Risk summary: The amount of cases, issues and findings associated with the IaC resource. Each of
these types includes two clickable values. The first value redirects to the corresponding type table
sorted by the entry, while the second value opens the description card of the specific type within the IaC
resource asset inventory without requiring redirection

Visibility timeline: When the IaC resource was first and last detected

Properties:

Asset details, including Asset Id, Asset Category and Account ID associated with the IaC resource

Source Control Information: Displays the origin and location of the IaC resource's code. It includes the
cloud provider (such as AWS), the provider hosting the code (such as GitHub, GitLab), the linked
repository and branch in which the code is hosted, associated tags, and the exact file path to the
resource's definition

Version History and Metadata: Provides insights into the resource's development history, authorship, and
associated metadata. It lists collaborators who have modified the IaC code, and details about the initial
commit hash and time related to this IaC asset

Scan information: A list of scans conducted on the IaC resource. Scan details include the name of the
scanner used, the specific branch of the package that was scanned, the timestamp of the last scan,
and the overall status of the scan (such as completed or failed)

For more information about scan management, refer to Overview.

The Highlights section and other asset properties only display attributes when their corresponding indicators
are present. For example, if an asset is not deployed, its deployment-related attributes will not show up;
similarly, if there are no detected issues, those highlights or properties will not appear.

Code
The Code tab describes the directory path and file name where the asset's resource code resides within your
IaC repository. In addition, the code defining the resource block is displayed.

Code to Cloud

The Code to Cloud tab describes the integrated flow of a selected Infrastructure as Code (IaC) asset, from
development to its deployed state. The graph visualizes the path to production, showing the IaC resource's
journey from the repository node where it's hosted, through the CI/CD system, and finally to the traced runtime
resource it provisions.

Applications

The Applications tab provides an overview of the application associated with this IaC asset, including a
graphical representation of its path to production, which incorporates the IaC assets role within the workflow.

For more information about applications, refer to Business application assets.

Configurations

The Configurations tab displays an inventory of IaC misconfiguration detected in the asset.

The table includes the following exposed properties:

Severity level (icon): Indicates the level of severity of the IaC misconfiguration

Issue Name: The IaC misconfiguration identifier

Asset Name: The name of the IaC resource in which the misconfiguration occurred

Assigned To: The person or team responsible for addressing the vulnerability

Creation Date: The date when the vulnerability was detected

For more information about IaC misconfiguration, refer to Infrastructure as Code (IaC) scanners.

Secrets

The Secrets tab displays an inventory of exposed Secrets in the IaC asset.

The table includes the following exposed properties:

Severity level (icon): Indicates the level of severity of the exposed Secrets

Issue Name: The Secrets identifier

Assigned To: The person or team responsible for addressing the Secrets

Creation Date: The date when the Secrets were initially detected

For more information about Secrets, refer to Secrets scanners.

6 | Code Security scanners

The Code Security module provides automated, native scanning tools designed to enhance the security
posture of your applications and infrastructure. Integrating these scanners into your development workflow
facilitates a "shift-left" approach to security, enabling the proactive identification and remediation of
vulnerabilities early in your software development lifecycle (SDLC).

The module includes both native scanners and the capability to ingest data from third-party scanners, giving
you comprehensive visibility into your security posture.

Code Security scanners include:

Software Composition Analysis (SCA) scanners: Modern applications frequently incorporate numerous
open-source and third-party packages. Code Security SCA scanners automate the inspection of these
dependencies. They identify known vulnerabilities (tracked as CVEs), assess license compliance to
mitigate legal risks, and detect package operational risks such as outdated or unmaintained
components. This provides critical insight into your software's complete composition, enabling informed
decisions about external code. For more information refer to Software Composition Analysis (SCA )
scanners

Secrets scanner: The accidental exposure of sensitive credentials—including API keys, passwords, or
tokens—within source code or configuration files represents a significant security risk. The Code
Security module secrets scanner detects hardcoded secrets across your repositories and code. Early
identification of these exposures prevents unauthorized access and potential data breaches. For more
information refer to Secrets scanners

Infrastructure as Code (IaC) scanners: Analyze your infrastructure configuration files prior to deployment
to detect misconfigurations, insecure defaults, and compliance violations, thereby preventing the
introduction of vulnerabilities into your operational environments. For more information refer to
Infrastructure as Code (IaC) scanners

In addition to the native code security scanners, Cortex Cloud Cloud ingests data from third-party scanners.
This allows you to consolidate your security findings and manage them all within a single platform for a holistic
view of your security posture. For more information about third party scanners, refer to Supported third-party
data sources

7 | Secrets scanners
Abstract

Cortex Cloud Application Security Secrets scans identify sensitive data embedded in your codebase. This
proactive scanning approach ensures that sensitive information is detected and addressed early in the
Software Development Lifecycle, significantly reducing the risk of such issues reaching production
environments.

Secrets use cases

Detect exposed sensitive data: Identify hardcoded credentials, API keys, passwords, tokens, encryption
keys, certificates, and pass-phrases found directly within your source code or configuration files

Prevent unauthorized access and data breaches: By enabling the early identification of these exposures,
secrets scans help prevent unauthorized access and potential data breaches that could compromise
your infrastructure and applications
Supported file types: Cortex Cloud Application Security scans any plaintext files that are not encrypted, not
compressed (for example, not .zip files) and not compiled (for example, not .jar files), for secrets. Additionally,
entropy findings look for keywords to lower the noise, and those keywords must be in line with the high entropy
string to be flagged.

Entropy Analysis: Cortex Cloud Application Security provides signatures that analyze the randomness of
strings within the file. Highly random strings, often referred to as high entropy, can be indicative of a potential
secret. To reduce false positives, Cortex Cloud Application Security considers specific keywords that might be
associated with secrets alongside the randomness of the data for better accuracy.

You can create policies to automatically detect and prevent the introduction of vulnerable open-source
components into your codebase. These policies ensure that all third-party dependencies align with your
organization's security standards and risk tolerance, helping you maintain a secure software supply chain. For
more information about creating secrets policies, refer to Create Cortex Cloud Application Security policies.

7.1 | Secretsissues
Valid secret findings exposed during scans, and classified as Critical or High by Cortex Cloud Application
Security policies, are categorized as issues, which represent the smallest unit for remediation in Cortex Cloud.
Each issue includes a description, its potential impact, and evidence of the finding that generated the issue in
the code.

The Cortex Cloud Application Security Secrets inventory is a pre-filtered view of the comprehensive Cortex
Cloud Issues inventory (located at Cases & Issues → Issues). This Secrets inventory displays only issues
generated by Cortex Cloud Application Security scanners, while the platform Cortex Cloud Issues inventory
unifies all issues from all platform scanners.

Cortex Cloud Application Security provides contextual risk indicators that extend beyond basic severity
scoring, providing a clearer view of an issue's exposure and priority. The proprietary Urgency metric
dynamically evaluates risk based on factors such as visibility and validation, providing additional context by
assessing exploit probability and inherent severity.

Cortex Cloud Application Security provides detailed manual guidance to remediate Secrets issues. You can
access these remediation steps directly in the Actions tab of the issue side panel.

How to access Secrets issues

Under Modules, select Application Security → Issues → Secrets.

You can also view Secrets issues in dedicated tabs under other sections when available:

In Code asset inventories: navigate to Inventory → All Assets → Code:

On the Secrets tab under Repositories. Refer to In-depth repository asset informationfor more
information

Under the All Code inventory: Select an asset from the table → Secrets

In Application asset inventories: navigate to Inventory → All Assets → Application → select an option
from the Application menu → select an item from the inventory → Secrets

In Cases and Issues; perform a query. Select Issues → AppSec Issues (under the All Domains menu)
→ Secrets (as the Detection Method value)
7.2 | Secrets issues inventory
The Secrets issues inventory includes the following properties. Use the Table Settings Menu to view additional
properties.

Property Description

Severity Severity level of the secret exposure (such as

Critical, High, Medium, Low)

Name Name or description of the secret exposure type

Asset Name Name of the resource or asset where the secret

was exposed. Selecting an Asset Name in the
table opens the asset's side card, displaying
information about the asset, without having to
navigate away from the issue page.

Urgency A context-aware metric to help you focus

remediation efforts on the issues that pose the
greatest real-world risk in your code. Urgency
enrichment highlights risks based on specific, high-
impact factors such as deployment status and
runtime exposure. For more information about
Urgency, refer to Urgency

Risk Factors Specific conditions that increase the exposure or

exploitability of a secret. Options: Found in history,
Valid, Privileged

AppSec Policy The Application Security policy that identified the

specific security policy that was violated, which
triggered the scanner to generate this issue.
Selecting a policy in the table opens the policy side
card, displaying a summary of the policy, without
having to navigate away from the issue page. For
more information about Application Security
policies, refer to Application Security Policies

Data Source The system or integration from which the issue data
was originally pulled (such as GitHub, GitLab)
 Property Description

SLA Application Security SLA defines deadlines for

fixing security issues based on severity, ensuring
timely remediation and improving team
performance. For more information about
Application Security SLA, refer to Service Lead
Agreements (SLA)

Rule Category The category associated with the rule that detected
the secret

Status The current state of the issue. Options: New, In

Progress, Resolved

File Path Path to the file or location within the code where the
secret was exposed

Assignee The individual responsible for addressing and

resolving the issue

Created Timestamp of when the secret exposure was first

detected

Backlog Status Indicates whether the issue is classified as pre-

existing technical debt (Backlog) or a newly
introduced vulnerability (New). For more on
Backlog status, refer to Backlog baseline

Business Applications Business applications that includes assets in which

the exposed secret was detected

Organization The organization within the VCS in which the issue

was detected

Branch The specific branch or version of the code where

the secret exposure was detected
 Property Description

Repository The version control repository where secret resides

Secrets validation

You can filter secrets based on their validation status. Options include:

Valid: The secret has been verified as active and functional

Invalid: The secret has been verified as no longer active or functional

Privileged: The secret is valid and provides access to sensitive resources or functions

No Validation: Validation was not attempted because the secret type or source does not support
verification

Unavailable: Validation could not be performed because the secret source was inaccessible or the
required permissions were missing

7.3 | Detailed Secrets issue information

When you click an issue in the table, a detailed side card opens, providing a concise summary at the top. This
summary includes the issue name, severity level, ID, category (such as Configuration, Vulnerability, Data), the
detecting scanner type, and the age of the issue. The Overview tab then provides in-depth information about
the issue.

Overview
 Issue metadata

Timestamp: When the issue was created and last updated

Status: Displays the current state of the issue. Values: New, In Progress, Resolved. You can set
the status as required

Assignee: The entity assigned to mitigate the issue. You can assign the issue to a person
responsible for resolving this issue

AppSec Rule: The Cortex Cloud Application Security rule that detected the finding. Selecting the
link in the field redirects to the AppSec Rules table, filtered by the selected rule

AppSec Policy: The violated security standard that led to the detection and creation of the issue.
Selecting the link in the field redirects to the AppSec Policies table, filtered by the selected policy

Backlog: Indicates if the issue is categorized as Backlog (pre-existing technical debt) or New (a
recently introduced vulnerability). To understand how issues are categorized as backlog/new,
refer to Issue/Finding classification by scanner

Description: A description of the issue

Asset Type: The specific asset in which the issue was identified. Clicking on the asset opens the asset
side card without needing to navigate away to the asset table

Linked Cases: The number and severity of cases associated with this issue.

Evidence: Provides evidence and contextual details about the finding:

Data Source: The system or integration from which the issue data was originally pulled (such as
GitHub or a CI/CD pipeline). Click the icon next to the data source to navigate to the data source
itself

Location: The location of the finding, including the repository, branch, file path, and code

Collaborator: The individual or team responsible for contributing to the code or configuration
where the issue was identified

Commit Hash: The commit hash of the most recent commit that modified the code where the issue
was detected

Commit Time: The timestamp of the most recent commit that modified the code where the issue
was detected

Urgency Details: The issue's urgency level, a breakdown of its contributing metrics, and the date it was
last updated. In addition, a graph visualizes the asset in which the issue's urgency context was
detected. Selecting the node in the graph provides additional information

For more information about Urgency levels, refer to Urgency.

Remediation: Suggested steps to mitigate the issue. For a complete list of remediation options, including
automatic fixes, refer to the Actions tab below

NOTE:

Different issue types include different properties; therefore, not all properties are available for every issue.
Actions

Includes a manual fix where applicable. Automated fixes are not available for secrets issues.

War Room

The War Room provides an audit trail of all automatic or manual actions taken on an issue, serving as a
dedicated space to review and interact with your issue. Each issue has a unique War Room. With machine
learning insights, the Cortex Cloud platform suggests the most effective analysts and command sets to help
you address issues efficiently.

7.4 | Secrets findings

Secrets findings display sensitive information, such as credentials or API keys, that may be exposed within
your assets. These insights help assess and analyze the potential exposure of secrets in your environment.

The Cortex Cloud Application Security Secrets Findings table is a pre-filtered view of the comprehensive
Findings inventory (located at Cases & Issues → Issues → Findings Table tab).

This table exclusively displays findings from the Cortex Cloud Application Security Secrets scanner that were
detected during periodic scans. In contrast, the comprehensive Findings table unifies vulnerabilities findings
from all sources, including periodic, pull request (PR), and continuous integration (CI) scans.

NOTE:

Findings are informational and, as such, are not directly mitigable. Remediation is performed on issues
derived from findings.

To access Secrets findings, select Application Security → Issues → Secrets → click the Findings tab.

Secrets findings inventory

The Secrets Findings inventory includes the following properties. Use the Table Settings Menu to view
additional properties.

Property Description

Name The name or title of the finding.

Asset Name Name of the asset affected by the finding.

Selecting an Asset Name in the table opens the
asset's side card, displaying information about the
asset, without having to navigate away from the
Findings page.
 Property Description

Risk Factors Quantifiable attributes of a finding, allowing you to

analyze and assess the risk. Options: Found in
history, Valid, Privileged

Data Source Source of the finding information (the version

control system)

Rule Category The category assigned to the rule that detected the
finding

Repository Name of the repository hosting the asset in which

the finding was detected

Branch The branch of code or version control branch

where the finding was detected

File Path The file path or location within the repository where
the finding was located

Backlog Status Backlog Status: Indicates if the finding is

categorized as Backlog (pre-existing technical
debt) or New (a recently introduced vulnerability).
To understand how findings are categorized as
backlog/new, refer to Issue/Finding classification
by scanner

Expanded Findings details

Clicking on a finding in the inventory table opens the Findings side card which provides additional details.
Finding summary: Found at the top of the card. Includes the finding name, ID and type (Data for Secrets
findings)

Description: A description of the finding including its location

Impact: The potential security risk the finding poses to your environment

Timestamp: When the finding was last updated

Asset details: Includes Asset (The impacted asset. Clicking on the asset opens the asset side card
without needing to navigate away to the asset section) and Asset Type (The specific asset type in which
the secret was identified, , such as JavaScript Package)

Evidence: Provides evidence and contextual details within your software development lifecycle
containing the finding:

Finding source

Data Source: The system or integration from which the finding data was originally pulled
(such as GitHub or a CI/CD pipeline). Click the icon next to the data source to navigate to
the data source itself

Run ID: The unique identifier of the specific scan execution during which this finding was
detected

Code context

Branch: The specific branch within the repository containing the finding

File Path: The exact location of the finding within the repository file structure

First Hash: The commit hash of the first commit where this specific finding was introduced
or detected

First Commit Date: The date of the commit that introduced the problematic code or
dependency into the repository. This helps understand how long an issue has existed and
for prioritizing remediation efforts based on its age

Backlog Status: See the inventory table above

Collaborator. The entity associated with the finding, contributing to or responsible for the
evidence supporting it

Code: the code line including the finding

Scan metadata

Rule ID: The ID of the rule that triggered the finding

Prioritization Labels: Labels assigned to a finding (such as No Validation), which allow you
to prioritize findings for further analysis or mitigation

Manual Fix Suggestion: Remediation options

7.5 | Manage Secrets issues
You can take the following actions to address and manage Secrets exposure issues:

Right-click on a row in the inventory table to access the following actions

Change Status. Modify the status of the issue. Values: New, In Progress, Resolved

Change Severity: Modify the severity level of the issue. Values: Critical, High, Medium, Low

Change Assignee: Change the user or identity assigned to address the issue

Copy text to clipboard: Duplicate selected text for easy pasting elsewhere

Copy entire row: Duplicate the entire row of data for easy pasting elsewhere

Copy issue URL: Duplicate the URL associated with the issue, to share or reference the issue

Show/hide rows with the [severity level]: Show/hide rows matching the [severity level] of the selected
row

8 | Infrastructure as Code (IaC) scanners

Abstract

IaC scanners safeguard cloud infrastructure by identifying misconfigurations before deployment, preventing
vulnerabilities in your operational environment.

IaC scanners safeguard your cloud infrastructure by identifying security risks in your infrastructure
configurations before they are deployed.

By analyzing your infrastructure configuration files prior to deployment, IaC scanners help prevent the
introduction of vulnerabilities into your operational environments.

IaC use cases

Proactive detection: IaC scans identify and flag critical issues such as misconfigurations, insecure
defaults, and compliance violations directly within your IaC templates. This includes detecting potential
risks in files for various frameworks (see Supported frameworks and languages for supported
frameworks)

Issue remediation: All Critical and High IaC misconfiguration findings are categorized as actionable
issues. The platform provides both manual and automated fixes to resolve these issues, streamlining
remediation efforts. Automated fixes for IaC misconfigurations can modify the configuration directly

Integration and developer efficiency: IaC scanning integrates seamlessly into development workflows.
Findings can be detected locally using the Cortex CLI or directly within supported IDEs (Visual Studio
Code, JetBrains) via plugins, providing real-time security feedback to developers as they write code.
This helps developers fix problems early, reducing rework and accelerating secure development

Policy enforcement: You can create and apply custom policies and rules that define how the system
responds to IaC threats, allowing for tailored security checks and automated actions such as blocking
CI runs or pull requests based on detected misconfigurations
8.1 | Supported frameworks and languages
Cortex Cloud Application Security supports the following infrastructure-as-code (IaC) frameworks.

Ansible Dockerfile OpenAI

ARM Helm OpenTofu

Bicep Kubernetes Terraform

CloudFormation Kustomize Terraform Plan

8.2 | IaC misconfiguration issues

All Critical and High IaC misconfiguration findings detected in an organization's environment are categorized
as issues, which represent the smallest unit for remediating IaC resource misconfigurations. Where applicable,
both manual and automated fixes are provided to resolve these issues.

The IaC misconfiguration Issues table is a filtered instance of the broader Issues table found under Cases &
Issues, meaning it exclusively displays issues categorized as IaC misconfigurations. The IaC misconfiguration
Issues table only displays issues generated from findings detected during periodic scans. In contrast, the
comprehensive Issues table includes all IaC misconfiguration issues, regardless of their detection source,
such as periodic, pull request (PR), and continuous integration (CI) scans.

How to access IaC misconfiguration issues

To access IaC misconfiguration issues, under Modules, select Application Security → Issues → IaC
misconfiguration.

TIP:

You can also view IaC misconfiguration issues in dedicated tabs under other sections when available:

In code Asset inventories, navigate to Inventory → All Assets → Code:

On the Configuration tab under Repository assets. Refer to In-depth repository asset information
for more information

Under the All Code asset inventory: Select an asset from the table → click the Configuration tab

In Application asset inventories, when an application includes an IaC asset that includes a detected
misconfiguration: navigate to Inventory → All Assets → Applications → select an option from the
Applications menu → select an application from the inventory → Configurations

Under Cases and Issues; perform a query. Select Issues → AppSec Issues (under the All Domains
menu) → IaC Scanner (as the Detection Method value)
8.3 | IaC misconfiguration issues inventory
The IaC misconfiguration issues inventory includes the following properties. Use the menu to view additional
fields.

Read more...

Property Description

Severity The level of risk or impact associated with the

finding, typically categorized (such as Critical,
High, Medium, Low).

Name The specific name or title of the finding, clearly

identifying the detected issue

Asset Name The name of the asset (such as a repository) where

the issue was identified

Framework The Infrastructure as Code (IaC) framework or

language used for the asset (such as
CloudFormation, Terraform, Azure Resource
Manager, Kubernetes)

Repository The version control repository where the

problematic code or configuration resides

Data Source The system or integration from which the data was
originally pulled (such as GitHub, GitLab)

Branch The specific branch within the repository where the

issue was detected

File Path The exact path to the file within the repository's
structure where the issue is located

Status The current state of the issue (New, In Progress,

Resolved)
 Property Description

Assignee The individual responsible for addressing and

resolving the issue

Backlog Status Indicates whether the issue is classified as pre-

existing technical debt (Backlog) or a newly
introduced misconfiguration (New). For more on
Backlog status, refer to Backlog baseline

8.4 | Detailed IaC issue information

Click on an issue in the table to open a detailed side-card, which provides additional, more in-depth
information about the issue. A concise summary of the issue is displayed at the top of the page. The
information is organized into tabs, including an Overview tab (default display) which provides highlights and a
general summary, while contextual tabs focus on particular details of the issue.

Overview
 Issue metadata

Timestamp: When the issue was created and last updated

Status: Displays the current state of the issue. Values: New, In Progress, Resolved. You can set
the status as required

Assignee: The entity assigned to mitigate the issue. You can assign the issue to a person
responsible for resolving this issue

AppSec Rule: The Cortex Cloud Application Security rule that detected the finding. Selecting the
link in the field redirects to the AppSec Rules table, filtered by the selected rule

AppSec Policy: The violated security standard that led to the detection and creation of the issue.
Selecting the link in the field redirects to the AppSec Policies table, filtered by the selected policy

Backlog: Indicates if the issue is categorized as Backlog (pre-existing technical debt) or New (a
recently introduced vulnerability). To understand how issues are categorized as backlog/new,
refer to Issue/Finding classification by scanner

Description: A description of the issue

Asset Type: The specific asset in which the issue was identified. Clicking on the asset opens the asset
side card without needing to navigate away to the asset table

Linked Cases: The number and severity of cases associated with this issue.

Evidence: Provides evidence and contextual details about the finding:

Data Source: The system or integration from which the issue data was originally pulled (such as
GitHub or a CI/CD pipeline). Click the icon next to the data source to navigate to the data source
itself

Location: The location of the finding, including the repository, branch, file path, and code

Collaborator: The individual or team responsible for contributing to the code or configuration
where the issue was identified

Commit Hash: The commit hash of the most recent commit that modified the code where the issue
was detected

Commit Time: The timestamp of the most recent commit that modified the code where the issue
was detected

Urgency Details: The issue's urgency level, a breakdown of its contributing metrics, and the date it was
last updated. In addition, a graph visualizes the asset in which the issue's urgency context was
detected. Selecting the node in the graph provides additional information

For more information about Urgency levels, refer to Urgency.

Remediation: Suggested steps to mitigate the issue. For a complete list of remediation options, including
automatic fixes, refer to the Actions tab below

NOTE:

Different issue types include different properties; therefore, not all properties are available for every issue.
Code to Cloud

The Code to Cloud tab provides a trace from the IaC misconfiguration issue to its impact on your runtime
environment, displaying a list of traced runtime findings and traced runtime issues:

The Traced Runtime Issues table includes these exposed properties

Severity: The level of risk associated with the issue

Issue Name: The name of the specific issue detected

Assigned to: Indicates the individual responsible for remediating the issue

Asset Name: The name of the runtime asset where the issue was detected

Detection Method: The method used to identify the issue, such as a specific scanner or security
tool

Observation Time: The time and date when the issue was first observed in the runtime
environment

The Traced Runtime Findings table includes these exposed properties

Finding Name: The specific name of the finding detected on the asset.

Asset Name: The name of the runtime asset where the finding was detected.

Detection Method: The method used to identify the finding.

Observation Time: The time and date when the finding was first observed.

Actions

This tab includes suggested steps to fix the issue. When an automatic fix is available, you can apply it directly
by selecting Open Fix Pull Request. Otherwise, manual steps are provided to guide you through remediation.

War Room

The War Room provides an audit trail of all automatic or manual actions taken on an issue, serving as a
dedicated space to review and interact with your issue. Each issue has a unique War Room. With machine
learning insights, the Cortex Cloud platform suggests the most effective analysts and command sets to help
you address issues efficiently.

8.5 | IaC misconfiguration findings

IaC misconfiguration scans produce findings, which are potential security risks in your Infrastructure-as-Code
(IaC) definitions. These insights help assess and analyze the security posture of your IaC assets.

The IaC misconfiguration Findings table is a filtered instance of the broader Findings table found under Cases
& Issues, meaning it exclusively displays findings categorized as IaC misconfiguration findings.

NOTE:

Findings are informational and, as such, are not directly mitigable. Remediation is performed on issues
derived from findings.
To access IaC misconfiguration findings, under Modules, select Application Security → Issues → IaC
Misconfigurations → click the Findings tab.

Findings inventory

The Findings inventory includes the following exposed properties.

Read more...

Property Description

Name The specific name or title of the finding (follows the

name of the rule)

Asset Name The name of the asset (such as a repository) where

the finding was identified

Repository The version control repository where the

problematic code or configuration resides

Data Source The system or integration from which the finding

data was originally pulled (such as GitHub, GitLab)

Branch The specific branch within the repository where the

finding was detected

File Path The exact path to the file within the repository's
structure where the finding is located

Expanded Findings details

Clicking on a finding in the inventory table opens the Findings side card which provides additional details
about the finding.

Read more...
 Finding summary: Found at the top of the card. Includes the finding name, ID and type (Configuration
for IaC findings)

Description: A description of the finding including its location

Timestamp: When the finding was last updated

Asset details: Includes Asset (The impacted asset. Clicking on the asset opens the asset side card
without needing to navigate away to the asset section) and Asset Type (The specific asset type in which
the IaC resource was identified)

Evidence: Provides evidence and contextual details within your SDLC containing the IaC
misconfiguration finding:

Finding source

Data Source: The system or integration from which the finding data was originally pulled
(such as GitHub or a CI/CD pipeline). Click the icon next to the data source to navigate to
the data source itself

Run ID: The unique identifier of the specific scan execution during which this finding was
detected

Collaborator: The individual or team responsible for contributing to the code or configuration
where the finding was identified

Code context

Repository: The name of the version control repository where the finding was located

Branch: The specific branch within the repository containing the finding

File Path: The exact location of the finding within the repository file structure

First Hash: The commit hash of the first commit where this specific finding was introduced
or detected

First Commit Date: The date of the commit that introduced the problematic code or
dependency into the repository. This helps understand how long an issue has existed and
for prioritizing remediation efforts based on its age

Scan metadata

Run ID: The unique identifier of the specific scan execution during which this finding was
detected

8.6 | Manage IaC misconfiguration issues

You can take the following actions to address and manage IaC misconfiguration issues:

Right-click on a row in the inventory table to access the following actions

 Change Status. Modify the status of the issue. Values: New, In Progress, Resolved

Change Severity: Modify the severity level of the issue. Values: Critical, High, Medium, Low

Change Assignee: Change the user or identity assigned to address the issue

Copy text to clipboard: Duplicate selected text for easy pasting elsewhere

Copy entire row: Duplicate the entire row of data for easy pasting elsewhere

Copy issue URL: Duplicate the URL associated with the issue, to share or reference the issue

Show/hide rows with the [severity level]: Show/hide rows matching the [severity level] of the selected
row

Open Fix PR: Create a Pull Request (PR) with a suggested fix to remediate the issue

9 | Software Composition Analysis (SCA ) scanners

Cortex Cloud Application Security SCA scanners inspect and manage the security and compliance of your
application's open-source and third-party dependencies. They are part of the Cortex Cloud shift-left security
strategy, enabling organizations to proactively identify and mitigate risks associated with external code
components early in the development lifecycle.

Currently, support for SCA is limited to static analysis, meaning that only direct dependencies are scanned.
However, if lock files are present, support is extended to include the analysis of transitive dependencies as
well.

SCA use cases

SCA provides a comprehensive approach to securing your software supply chain by enabling you to achieve
these objectives:

Gain comprehensive visibility into Software Composition: SCA tools build a complete inventory of all
open-source packages and their dependencies, providing critical insight into your software's entire
composition. This unified view helps you understand and manage your overall software supply chain.
Refer to Software packages as assets for more information

Improve application code security and prioritizing remediation: SCA scans identify critical vulnerabilities
and prioritize remediation efforts based on a data-driven risk assessment that combines code-level
vulnerabilities and potential business impact

Enable informed decisions about external code: By providing detailed insights into vulnerabilities,
licenses, and operational risks, SCA empowers development and security teams to make informed
decisions about the use, update, or replacement of external code components

SCA achieves these objectives by performing the following core functions:

 Identify known vulnerabilities (CVEs): Automatically detect and flag known security vulnerabilities
(tracked as Common Vulnerabilities and Exposures or CVEs) present in your open-source and third-
party dependencies. This provides crucial insights into potential weaknesses that could be exploited

Assess license compliance: Manage open-source license obligations and identify potential compliance
risks introduced by your application's components. This helps you adhere to regulatory requirements
and minimize legal and compliance exposure

Detect Package Operational Risks: Evaluate the operational health and potential long-term risks of
open-source packages, such as assessing their popularity, maintenance status (such as outdated or
unmaintained components), and deprecation status. This allows you to proactively manage threats from
abandoned or insecure components

9.1 | Supported Software Composition Analysis (SCA) frameworks and

languages
The following table provides the SCA languages supported by Cortex Cloud.

Language Vulnerabilities Operational Risk License DetectionTransitive Dependencies

Root Fix Detection

JavaScript Yes Yes Yes Yes Yes

Python Yes Yes Yes Yes Yes

Go Yes Yes Yes Yes Yes

Java Yes Yes Yes Yes Yes

Kotlin Yes Yes Yes Yes Yes

Ruby Yes No No Yes No

.NET (C#) Yes Yes Yes Yes Yes

SCA support matrix by language

The following table provides a high-level overview of Cortex Cloud SCA's language support. Clicking on any
listed language will navigate to a dedicated section with more in-depth details about the language.
 Language Package Managers Manifest Files

JavaScript npm [Link]

[Link]

yarn [Link]

[Link]

Python pip [Link]

Pipfile

[Link]

GO Go [Link]

[Link]

[Link]

Java Maven [Link]

Gradle [Link]

[Link]

Kotlin Maven [Link]

Gradle [Link]

[Link]

Ruby — Gemfile

[Link]

gemspec
 Language Package Managers Manifest Files

,NET — .csproj

[Link]

[Link]

[Link]

[Link]

9.2 | Software Composition Analysis (SCA) vulnerability issues

Vulnerability findings detected in software packages with a Critical or High severity level are categorized as
SCA issues, which represent the smallest actionable unit for remediations in Cortex Cloud. Each issue
includes a description, its potential impact, and evidence of the finding that generated the issue in the code.

The Cortex Cloud Application Security Vulnerabilities inventory is a pre-filtered view of the comprehensive
Cortex Cloud Issues inventory (located at Cases & Issues → Issues). This Vulnerabilities inventory displays
only issues generated by Cortex Cloud Application Security scanners and ingested third party vulnerability
findings, while the platform Cortex Cloud Issues inventory unifies all issues from all platform and third-party
scanners.

Cortex Cloud Application Security provides contextual risk indicators that extend beyond basic severity
scoring, providing a clearer view of an issue's exposure and priority. The proprietary Urgency metric
dynamically evaluates risk based on factors such as deployment context, runtime exposure, and exploit
likelihood, while industry-recognized standards such as EPSS and CVSS provide additional context by
assessing exploit probability and inherent severity.

Cortex Cloud Application Security provides detailed manual guidance and automated fixes, when available, to
remediate issues. You can access these remediation steps directly in the Actions tab of the issue side panel.

How to access CVE vulnerability issues

To access CVE vulnerability issues, under Modules, select Application Security → Issues → Vulnerabilities.

You can also view SCA vulnerabilities in dedicated tabs under other sections when available:

Read more...
TIP:
 In Asset inventories, navigate to Inventory → All Assets → Code:

On the Vulnerabilities tab under Repositories. Refer to In-depth repository asset information for
more information

Under the All Code inventory: Select an asset from the table → Vulnerabilities

On the Applications inventory: Navigate to Inventory → All Assets → Applications → select an option
from the Applications menu → select an application from the inventory → Vulnerabilities

In Cases and Issues; perform a query. Select Issues → AppSec Issues (under the All Domains menu)
→ AppSec CVE Scanner (as the Detection Method value)
9.2.1 | Vulnerability issues inventory

The CVE vulnerability issues inventory includes the following SCA attributes. Use the Table Settings Menu to
view additional properties.

Field/Attribute Description

Severity The severity level of the issue. You can change the
severity level directly in the table: Right-click on an
issue → Change Severity → select a severity level

Name The unique identifier assigned to the CVE

Asset Name Name of the asset affected by the issue. Selecting

an Asset Name in the table opens the asset's side
card, displaying information about the asset,
without having to navigate away from the issue
page. For more information about software
package assets, refer to Software packages as
assets

Urgency A context-aware metric to help you focus

remediation efforts on the issues that pose the
greatest real-world risk in your code. Urgency
enrichment highlights risks based on specific, high-
impact factors such as deployment status and
runtime exposure. For more information about
Urgency, refer to Urgency

CVSS Score Common Vulnerability Scoring System (CVSS)

score representing the severity of the vulnerability
 Field/Attribute Description

EPSS Score The Exploit Prediction Scoring System (EPSS)

provides a data-driven probability score (from 0 to
1, or 0% to 100%) that indicates the likelihood of a
given CVE being exploited in the wild within the
next 30 days

Repository Name of the repository where the affected

package is hosted

AppSec Policy The Application Security policy that identified the

specific security policy that was violated, which
triggered the scanner to generate this issue.
Selecting a policy in the table opens the policy side
card, displaying a summary of the policy, without
having to navigate away from the issue page. For
more information about Application Security
policies, refer to Application Security Policies

Data Source The system or integration from which the data was
originally pulled (such as GitHub, GitLab)

SLA Application Security SLA defines deadlines for

fixing security issues based on severity, ensuring
timely remediation and improving team
performance. For more information about
Application Security SLA, refer to Service Lead
Agreements (SLA)

Branch The specific branch or version of the code where

the vulnerability was detected

File Path Path to the file or location within the code where the
vulnerability was detected
 Field/Attribute Description

Status The current state of the issue (New, In Progress,

Resolved). You can change the issue status
directly in the table: Right-click on an issue →
Change Status → select a status option. Note that
you can also change the status from the Overview
card in the issue side panel

Assignee The individual responsible for addressing and

resolving the issue. You can change an assignee
directly in the table: Right-click on an issue →
Change Assignee → select a user → OK

Scanner The scanner that detected the issue

Created Timestamp of when the issue was first detected.

Backlog Status Indicates whether the issue is classified as pre-

existing technical debt (Backlog) or a newly
introduced vulnerability (New). For more
information about Backlog Status, refer to Backlog
baseline

Business Application Names Business applications which includes assets in

which the issue was detected

CVE Risk Factors Attributes (such as Severity, Attack Vector, Attack

Complexity, Exploit Exists) indicating the potential
severity and likelihood of exploitation for a given
CVE

Automatic Fix Available Whether automatic fixes are available to remediate

the issue. Values: Yes/No

Manual Fix Available Whether manual fixes are available to remediate

the issue. Values: Yes/No
9.2.2 | Detailed vulnerability issue information

When you click an issue in the table, a detailed side card opens, providing a concise summary at the top. This
summary includes the issue name, severity level, ID, category (such as Configuration, Vulnerability, Data), the
detecting scanner type, and the age of the issue. The Overview tab then provides in-depth information about
the issue.

Overview
Issue metadata

Timestamp: When the issue was created and last updated

Status: Displays the current state of the issue. Values: New, In Progress, Resolved. You can set
the status as required from the field

Assignee: The entity assigned to mitigate the issue. You can assign the issue to a person
responsible for resolving this issue from the field

Affected Assets: The asset affected by the issue. Selecting this field opens the asset side card
displaying additional details about the asset without having to navigate away from the issues table
to the assets table.

Related Affected Assets: Additional assets affected by the issue

Package Manager: The package manager (such as Maven or npm) that hosts the vulnerable
package

AppSec Rule: The Cortex Cloud Application Security rule that detected the finding. Selecting the
link in the field redirects to the AppSec Rules table, filtered by the selected rule

AppSec Policy: The violated security standard that led to the detection and creation of the issue.
Selecting the link in the field redirects to the AppSec Policies table, filtered by the selected policy

Backlog Status: Indicates if the issue is categorized as Backlog (pre-existing technical debt) or
New (a recently introduced vulnerability). For more information about Backlog, refer to
Issue/Finding classification by scanner

Description: A description of the issue

Impact: Describes the potential risk if the issue is not addressed

Asset Type: The specific asset in which the issue was identified. Clicking on the asset opens the asset
side card without needing to navigate away to the asset table

Linked Cases: The number and severity of cases associated with this issue.

Evidence: Provides evidence and contextual details about the finding:

Data Source: The system or integration from which the issue data was originally pulled (such as
GitHub or a CI/CD pipeline). Click the icon next to the data source to navigate to the data source
itself

Location: The location of the finding, including the repository, branch, file path, and code

Collaborator: The individual or team responsible for contributing to the code or configuration
where the issue was identified

Commit Hash: The commit hash of the most recent commit that modified the code where the issue
was detected

Commit Time: The timestamp of the most recent commit that modified the code where the issue
was detected

Urgency Details: The issue's urgency level, a breakdown of its contributing metrics, and the date it was
last updated. In addition, a graph visualizes the asset in which the issue's urgency context was
 detected. Selecting the node in the graph provides additional information

For more information about Urgency levels, refer to Urgency.

Remediation: Suggested steps to mitigate the issue. For a complete list of remediation options, including
automatic fixes, refer to the Actions tab below
NOTE:

Not all properties are shown for every issue; availability depends on the context and the information collected
for that specific issue.

Code to Cloud

The Code to Cloud tab provides a trace from the vulnerability issue to its impact on your runtime environment,
displaying a list of traced runtime issues and traced runtime findings. You can filter the tables to narrow a
search, and additional table attributes through the Table Settings Menu.

The Traced Runtime Issues table includes the following exposed properties.

Severity: The level of risk associated with the issue.

Issue Name: The name of the specific issue detected.

Assigned to: Indicates the individual responsible for remediating the issue.

Asset Name: The name of the runtime asset where the issue was detected.

Detection Method: The method used to identify the issue, such as a specific scanner or security
tool.

Observation Time: The time and date when the issue was first observed in the runtime
environment.

The Traced Runtime Findings table includes these exposed properties:

Finding Name: The specific name of the finding detected on the asset.

Asset Name: The name of the runtime asset where the finding was detected.

Detection Method: The method used to identify the finding.

Observation Time: The time and date when the finding was first observed.

Actions

This tab includes suggested steps to fix the issue. When an automatic fix is available, the code is displayed
with the recommended fix. You can mitigate it by opening a fix PR: electing Open Fix Pull Request. By
selecting 'Open Fix Pull Request', a pull request will be automatically created on your behalf. No changes will
be made to the code until the PR is thoroughly reviewed and approved by your [Link], manual steps
are provided to guide you through remediation, including code examples where available.
 Automatic fix is available:

Displays the recommended code with the fix

Select Open Fix Pull Request to automatically create a pull request

The pull request is not merged automatically; it must be reviewed and approved by your team
before any changes are applied

Automatic fix not available:

Provides manual remediation steps

Includes code examples where applicable

War Room

The War Room provides an audit trail of all automatic or manual actions taken on an issue, serving as a
dedicated space to review and interact with your issue. Each issue has a unique War Room. With machine
learning insights, the Cortex Cloud platform suggests the most effective analysts and command sets to help
you address issues efficiently.

9.2.3 | CVE vulnerabilities findings

CVE vulnerabilities findings are specific, known security threats identified in your assets based on the CVE
system, providing insights into potential risks.

The Cortex Cloud Application Security Vulnerabilities Findings table is a pre-filtered view of the comprehensive
Findings inventory (located at Cases & Issues → Issues → Findings Table tab).

This table exclusively displays findings from Cortex Cloud Application Security SCA scanners that were
detected during periodic scans, and ingested third-party data. In contrast, the comprehensive Findings table
unifies vulnerabilities findings from all sources, including periodic, pull request (PR), and continuous
integration (CI) scans.

NOTE:

Findings are informational and, as such, are not directly mitigable. Remediation is performed on issues
derived from findings.

To access CVE findings, under Modules, select Application Security → Issues → Vulnerabilities → click the
Findings tab.

The CVE vulnerability findings inventory includes the following SCA attributes. Use the Table Settings Menu to
view additional properties.

Field/Attribute Description

CVSS Severity The Common Vulnerability Scoring System (CVSS)

severity level assigned to the finding
 Field/Attribute Description

CVE Common Vulnerabilities and Exposures identifier

associated with the finding

CVSS Score The Common Vulnerability Scoring System severity

score representing the severity of the vulnerability

EPSS Score Exploit Prediction Scoring System: The probability

(0-1) that estimates the likelihood of the
vulnerability being exploited in the wild within the
next 30 days

Name The CVE identifier

Package Manager The package management system used (such as

npm, Maven, pip)

Asset Name Name of the asset affected by the finding.

Selecting an Asset Name in the table opens the
asset's side card, displaying information about the
asset, without having to navigate away from the
Findings page.

Risk Factors Quantifiable attributes of a finding, allowing you to

analyze and assess the risk. Options: Found in
history, Valid, Privileged

Dependency Type Type of dependency (direct, transitive)

Repository Name of the repository hosting the asset in which

the finding was detected

Branch The specific branch or version of the code where

the vulnerability finding was detected
 Field/Attribute Description

File Path Path to the file or location within the code where the
vulnerability finding was detected

Data Source Source of the finding information (the version

control system)

Scanner The type of scanner that detected the finding

Backlog Status Backlog Status: Indicates if the finding is

categorized as Backlog (pre-existing technical
debt) or New (a recently introduced vulnerability).
To understand how findings are categorized as
backlog/new, refer to Issue/Finding classification
by scanner

Expanded Findings details

Clicking on a finding in the inventory table opens the Findings side card which provides additional details.
Finding summary: Found at the top of the card. Includes the finding ID and type (Vulnerability for CVE
vulnerability findings)

Description: A description of the finding including its location

Impact: The potential security risk the finding poses to your environment

Timestamp: When the finding was last updated

Asset details: Includes Asset (The impacted asset, such as cookie. Clicking on the asset opens the
asset side card without needing to navigate away to the asset section) and Asset Type (The specific
asset type in which the CVE vulnerability was identified, such as JavaScript Package)

Evidence: Provides evidence and contextual details within your software development lifecycle
containing the finding:
Finding source

Data Source: The system or integration from which the finding data was originally pulled
(such as GitHub or a CI/CD pipeline). Click the icon next to the data source to navigate to
the data source itself

Run ID: The unique identifier of the specific scan execution during which this finding was
detected

Code context

Repository: The name of the version control repository where the finding was located

Package Manager: The dependency management system (such as npm, Maven) used to
include or declare the software component where the finding was detected

Branch: The specific branch within the repository containing the finding

File Path: The exact location of the finding within the repository file structure

First Hash: The commit hash of the first commit where this specific finding was introduced
or detected

First Commit Date: The date of the commit that introduced the problematic code or
dependency into the repository. This helps understand how long an issue has existed and
for prioritizing remediation efforts based on its age

Root Package Name: The name of the primary software component analyzed by the scan

Root Package Version: The version of the primary software component analyzed by the
scan

CVE Information
 CVE ID: A unique identifier assigned to publicly known cybersecurity vulnerabilities,
allowing for standardized tracking and referencing.

CVE Description: A concise summary detailing the nature of the vulnerability, including its
affected products, impacts, and potential exploitation methods.

CVSS Severity: A qualitative ranking (e.g., Low, Medium, High, Critical) derived from the
CVSS score, indicating the overall severity of the vulnerability.

CVSS Score: A numerical score (0-10) representing the Common Vulnerability Scoring
System assessment of the vulnerability's characteristics and severity.

EPSS Score: The Exploit Prediction Scoring System score, a probability (0-1) estimating the
likelihood of a vulnerability being exploited in the wild within the next 30 days.

Fix Version: The specific software or component version in which the vulnerability has been
patched or resolved by the vendor.

Vendor Link: A direct URL to the official advisory, patch, or documentation provided by the
vendor regarding the vulnerability.

Risk Factors: Specific attributes or conditions that contribute to an issue's likelihood or the
severity of its impact, such as a lack of validation, hardcoded secrets, or unpatched
vulnerabilities.

Traced Runtime Findings: A list of vulnerabilities findings that were detected in your running application

9.2.4 | Manage SCA CVE vulnerability issues

Right-click on a row in the inventory table to access the following actions

Change Status. Modify the status of the issue. Values: New, In Progress, Resolved

Change Severity: Modify the severity level of the issue. Values: Critical, High, Medium, Low

Change Assignee: Change the user or identity assigned to address the issue

Copy text to clipboard: Duplicate selected text for easy pasting elsewhere

Copy entire row: Duplicate the entire row of data for easy pasting elsewhere

Copy issue URL: Duplicate the URL associated with the issue, to share or reference the issue

Show/hide rows with the [severity level]: Show/hide rows matching the [severity level] of the selected
row

9.3 | License miscompliance issues

All license miscompliance findings detected in software packages within an organization's environment are
defined as issues, which represent the smallest unit for remediating these violations. Manual fix suggestions
are provided to help resolve these issues.
The Licenses issues and findings tables are filtered views of the main issues and findings tables under Cases
& Issues, dedicated solely to license issues and findings detected during periodic scans.

Open source software licenses define the terms under which open source software can be used, modified,
and distributed. Cortex Cloud offers three types of default license categories out of the box, providing
comprehensive coverage for managing license compliance within your environment: Non Permissive
Licenses, Strong Copyleft Licenses, and Weak Copyleft Licenses. For more information refer to Open-source
software license categories.

How to access license miscompliance issues

To access license miscompliance issues, under Modules, select Application Security → Issues → Licenses.

Read more...
TIP:

You can also view license miscompliance issues in dedicated tabs under other sections when available:

In Application asset inventories: navigate to Inventory → All Assets → Application → select an option
from the Application menu → select an item from the inventory → Package Integrity

In Asset inventories, navigate to Inventory → All Assets → Code:

On the Licenses tab under Repositories. Refer to In-depth repository asset information for more
information

Under the All Code inventory: Select an asset from the table → Package Integrity

In Cases and Issues; perform a query. Select Issues → AppSec Issues (under the All Domains menu)
→ CAS License Scanner (as the Detection Method value)
9.3.1 | License miscompliance issues inventory

This table includes selected fields of the license miscompliance issues issues inventory.

Read more...

Field/Attribute Definition

Severity The severity level assigned to a detected license

compliance issue (such as high, medium, low).

Name The full name or text of the software license

License The identifier or short name of the associated

license (such as MPL-2.0).
 Field/Attribute Definition

Asset Name The name of the asset such as application, service)

that uses this license. Selecting the asset opens its
side panel, allowing you to view asset details
directly without leaving the issue

Package Manager The package manager used to install or manage

the software package including the license (such
as, npm, pip, maven)

License Category A categorization of the license based on its type

(such as strong copyleft )

Scan Source The type of scan that detected the issue, such as
periodic or pull request

Assignee The individual or team responsible for addressing

the license compliance issue

Created The date and time when the license compliance

issue was first detected or recorded

Click on an issue in the table to open a detailed side-card, which provides additional, more in-depth
information about the issue. A concise summary of the issue is displayed at the top of the page. The
information is organized into tabs, including an Overview tab (default display) which provides highlights and a
general summary, while contextual tabs focus on particular details of the issue.

Issue summary

The issue summary displayed at the top of the card provides concise details including the package manager
and the name and type of package in which the license miscompliance issue was detected.

Overview

The Overview tab provides general details of the license miscompliance:

Description: Provides a summary of the license miscompliance

Impact: The potential impact the license miscompliance issue could have on your SDLC

Status: The status of the issue. Values: New, In Progress, Resolved. You can modify the status of the
issue from the menu in the field

Assignee: The entity assigned to resolve the issue. By default the value is Unassigned. Select an
assignee from the menu in the field

Timestamps: Provides the date the issue was created and last updated

Affected Assets: Identifies the asset impacted by the issue. Selecting the asset opens its side panel,
allowing you to view asset details directly without leaving the issue or navigating to the dedicated Assets
section under Inventory

Linked Cases: The cases that the issue is linked to, including the amount of cases, their description and
severity. Selecting a case opens its side panel, allowing you to view case details directly without leaving
the issue or navigating to the dedicated Cases section under Cases & Issues

Evidence: Details and location in the codebase of the package containing the license miscompliance
issue
 Issue source and classification

Scanner Type: The type of security analysis tool that identified the license miscompliance
(The default is AppSec Package License Scanner)

Scanner Source: The specific platform or vendor providing the scanner. Cortex AppSec is
the default source

AppSec Policy: The Cortex Cloud Application Security policy that was triggered, leading to
the creation of this issue. Select the icon next to the policy name to navigate to the policy on
the AppSec Policies page

Backlog Status: Indicates if the issue is categorized as Backlog (pre-existing technical

debt) or New (a recently introduced license miscompliance issue). To understand how
issues are categorized as backlog/new, refer to Issue/Finding classification by scanner

Code context

Package Manager: The system (such as npm, pip) managing application dependencies
that contains the non-compliant license issue

Repository Name: The name of the version control repository where the license issue was
found

Branch: The specific development branch within the repository containing the license issue

File Path: The exact location of the license issue within the repository's file structure

Commit Hash: The unique identifier of the code change (commit) that is associated with the
license issue

Metadata

Data Source: The system or integration from which the issue was originally detected (such
as GitHub or CI/CD pipeline). Select the icon next to the data source redirects to the data
source

Remediation: Suggested remediation steps to address the issue. See Actions below for detailed
information

Actions

The Actions tab displays suggestions to fix the license miscompliance, including contacting your legal team
for further investigation.

9.3.2 | Expanded License miscompliance issues information

When you click an issue in the table, a detailed side card opens, providing a concise summary at the top. This
summary includes the issue name, severity level, ID, category (such as Configuration, Vulnerability, Data), the
detecting scanner type, and the age of the issue. The Overview tab then provides in-depth information about
the issue.

The issue summary displayed at the top of the card provides concise details including the package manager
and the name and type of package in which the license miscompliance issue was detected.
Overview

The Overview tab provides general details of the license miscompliance:

Description: Provides a summary of the license miscompliance

Impact: The potential impact the license miscompliance issue could have on your SDLC

Status: The status of the issue. Values: New, In Progress, Resolved. You can modify the status of the
issue from the menu in the field

Assignee: The entity assigned to resolve the issue. By default the value is Unassigned. Select an
assignee from the menu in the field

Timestamps: Provides the date the issue was created and last updated

Affected Assets: Identifies the asset impacted by the issue. Selecting the asset opens its side panel,
allowing you to view asset details directly without leaving the issue or navigating to the dedicated Assets
section under Inventory

Linked Cases: The cases that the issue is linked to, including the amount of cases, their description and
severity. Selecting a case opens its side panel, allowing you to view case details directly without leaving
the issue or navigating to the dedicated Cases section under Cases & Issues

Evidence: Details and location in the codebase of the package containing the license miscompliance
issue
 Issue source and classification

Scanner Type: The type of security analysis tool that identified the license miscompliance
(The default is AppSec Package License Scanner)

Scanner Source: The specific platform or vendor providing the scanner. Cortex AppSec is
the default source

AppSec Policy: The Cortex Cloud Application Security policy that was triggered, leading to
the creation of this issue. Select the icon next to the policy name to navigate to the policy on
the AppSec Policies page

Backlog Status: Indicates if the issue is categorized as Backlog (pre-existing technical

debt) or New (a recently introduced license miscompliance issue). To understand how
issues are categorized as backlog/new, refer to Issue/Finding classification by scanner

Code context

Package Manager: The system (such as npm, pip) managing application dependencies
that contains the non-compliant license issue

Repository Name: The name of the version control repository where the license issue was
found

Branch: The specific development branch within the repository containing the license issue

File Path: The exact location of the license issue within the repository's file structure

Commit Hash: The unique identifier of the code change (commit) that is associated with the
license issue

Metadata

Data Source: The system or integration from which the issue was originally detected (such
as GitHub or CI/CD pipeline). Select the icon next to the data source redirects to the data
source

Remediation: Suggested remediation steps to address the issue. See Actions below for detailed
information

Code to Cloud

The Code to Cloud tab provides a trace from the IaC misconfiguration issue to its impact on your runtime
environment, displaying a list of traced runtime findings and traced runtime issues:
 The Traced Runtime Issues table includes these exposed properties

Severity: The level of risk associated with the issue.

Issue Name: The name of the specific issue detected.

Assigned to: Indicates the individual responsible for remediating the issue.

Asset Name: The name of the runtime asset where the issue was detected.

Detection Method: The method used to identify the issue, such as a specific scanner or security
tool.

Observation Time: The time and date when the issue was first observed in the runtime
environment.

The Traced Runtime Findings table includes these exposed properties

Finding Name: The specific name of the finding detected on the asset.

Asset Name: The name of the runtime asset where the finding was detected.

Detection Method: The method used to identify the finding.

Observation Time: The time and date when the finding was first observed.

Actions

The Actions tab displays suggestions to fix the license miscompliance, including contacting your legal team
for further investigation.

War Room

The War Room provides an audit trail of all automatic or manual actions taken on an issue, serving as a
dedicated space to review and interact with your issue. Each issue has a unique War Room. With machine
learning insights, the Cortex Cloud platform suggests the most effective analysts and command sets to help
you address issues efficiently.

9.3.3 | License miscompliance findings

License miscompliance findings are potential licensing vulnerabilities in your open-source software packages.
These findings allow you to assess and analyze your package license compliance. Promoting these findings
to issues allows you to address license non-compliance. This ensures compliance with licensing requirements
and maintain the integrity of your software supply chain.

The Licenses Findings table is a filtered instance of the broader Findings table found under Cases & Issues,
meaning it exclusively displays findings categorized as license miscompliance findings. However, the
Licenses Findings table only displays findings detected during periodic scans. In contrast, the comprehensive
Findings table includes all license miscompliance findings regardless of their detection source, such as
periodic, pull request (PR), and continuous integration (CI) scans.
How to access license miscompliance findings

To access license miscompliance findings, under Modules, select Application Security → Issues → Licenses
→ click the Findings tab.
License miscompliance findings inventory

The license findings inventory includes the following properties.

Read more...

Field/Attribute Definition

Name The finding name including the category assigned,

such as Weak copyleft

License The specific license under which the software

package is distributed (such as MIT, GPL, Apache
2.0).

Asset Name The name of the asset such as application, service)

that uses this license

Package Manager The package manager used to install or manage

the software package including the license (such
as, npm, pip, maven)

Dependency Type Indicates whether the dependency is direct or

transitive

Repository The repository hosting the code in which the

license miscompliance was detected

Branch The branch containing the repository with the

license miscompliance

License Category A categorization of the license based on its type

(such as strong copyleft )
 Field/Attribute Definition

Data Source The version control system hosting the repository

with the license miscompliance

Created The date and time when the license compliance

issue was first detected or recorded

Finding ID The unique identifier assigned to the license finding

Backlog Status Backlog Status: Indicates if the issue is

categorized as Backlog (pre-existing technical
debt) or New (a recently introduced vulnerability).
To understand how issues are categorized as
backlog/new, refer to Issue/Finding classification
by scanner

Expanded Findings details

Clicking on a finding in the inventory table opens the Findings side card, which provides additional details
about the finding.

Read more...
 Finding summary: Found at the top of the card. Includes the finding name, ID and type (Code for
license miscompliance findings)

Description: A description of the finding including its location

Timestamp: When the finding was last updated

Asset details: Includes Asset (The impacted asset. Clicking on the asset opens the asset side card
without needing to navigate away to the asset section) and Asset Type (The specific asset type in which
the license miscompliance was identified)

Evidence: Provides evidence and contextual details within your SDLC containing the IaC
misconfiguration finding:

Finding source

Data Source: The system or integration from which the finding data was originally pulled
(such as GitHub or a CI/CD pipeline). Click the icon next to the data source to navigate to
the data source itself

Collaborator: The individual or team responsible for contributing to the code or configuration
where the finding was identified

License information

License. The license (MPL-2.0) including the miscompliance

License Category. The category assigned to the license. Refer to Open-source software
license categories for more information about license categories

OSI Approved. Whether the license is OSI approved or not

Code context

Repository: The name of the version control repository where the finding was located

Package Manager: The tool (such as PIP) that manages the dependency in which the
license miscompliance was detected

Branch: The specific branch within the repository containing the finding

File Path: The exact location of the finding within the repository file structure

First Hash: The commit hash of the first commit where this specific finding was introduced
or detected

Scan metadata

Run ID: The unique identifier of the specific scan execution during which this finding was
detected

9.3.4 | Open-source software license categories

Open-source software licenses define the terms under which open-source software can be used, modified,
and distributed. In Cortex Cloud Application Security, licenses are scanned as part of the SCA vulnerability
scan for open-source packages. All Critical, High and Medium license miscompliance detected in open-
source software packages within an organization's environment are defined as issues. This enables structured
vulnerability management and focused remediation. Where applicable, manual and automated fixes are
provided.

Cortex Cloud Application Security offers three types of default license categories out of the box, providing
comprehensive coverage for managing license compliance within your environment:

Non-Permissive Licenses (High severity)

Strong Copyleft Licenses (High severity)

Weak Copyleft Licenses (Medium severity)

Within each license type, SPDX identifiers are organized and sorted based on their characteristics and
attributes. SPDX Identifiers are unique codes assigned to software licenses by the Software Package Data
Exchange (SPDX) project. These identifiers are used to categorize and accurately identify software packages
distributed under various types of licenses, including strong copyleft, weak copyleft, and non-permissive
licenses. By associating each software package with a specific SPDX Identifier, it becomes easier to track and
manage license compliance across different licensing policies, ensuring that the correct license type is
identified and adhered to.

Non-permissive licenses

Non Permissive licenses policies identify software packages distributed under non-permissive or restrictive
licenses. These licenses restrict how you can use, modify, and distribute the software. They may limit your
ability to integrate the software into certain projects or require you to purchase a commercial license for
specific uses.

Non-permissive SPDX identifiers

The following list displays supported SPDX identifiers for non-permissive licenses.

Read more...
 BUSL-1.1

C-UDA-1.0

CC-BY-NC-3.0-DE

CC-BY-NC-ND-3.0-DE

CC-BY-NC-ND-3.0-IGO

CC-BY-NC-SA-2.0-DE

CC-BY-NC-SA-2.0-FR

CC-BY-NC-SA-2.0-UK

CC-BY-NC-SA-3.0-DE

CC-BY-NC-SA-3.0-IGO

CC-BY-ND-3.0-DE

Hippocratic-2.1

JPL-image

MS-LPL

NCGL-UK-2.0

PolyForm-Noncommercial-1.0.0

Strong copyleft licenses

Strong Copyleft licenses policies identify software packages distributed under strong copyleft licenses, such
as the GNU General Public License (GPL). These licenses require derivative works to be distributed under the
same copyleft license terms as the original work. This ensures broader access and modification rights.

Strong copyleft SDPX identifiers

The following list displays supported SPDX identifiers for strong copyleft licenses.

Read more...
 AGPL-1.0

AGPL-1.0-only

AGPL-1.0-or-later

AGPL-2.0

AGPL-3.0

AGPL-3.0-only

AGPL-3.0-or-later

Arphic-1999

CERN-OHL-S-2.0

copyleft-next-0.3.0

copyleft-next-0.3.1

GPL-2.0

GPL-3.0

Linux-man-pages-copyleft

OpenPBS-2.3

Weak copyleft licenses

Weak Copyleft Licenses policies identify software packages distributed under weak copyleft licenses. These
licenses permit combining code with other licenses, including proprietary licenses, without mandating the
entire derivative work to be released under the same copyleft license.

Weak copyleft SPDX identifiers

The following list displays supported SPDX identifiers for weak copyleft licenses.

Read more...
Artistic-1.0

Artistic-2.0

APSL

CAL-1.0-Combined-Work-Exception

CC-BY-SA-2.0-UK

CC-BY-SA-2.1-JP

CC-BY-SA-3.0-AT

CC-BY-SA-3.0-DE

CC-BY-SA-4.0

CDDL-1.0

CDLA-Sharing-1.0

CERN-OHL-W-2.0

CPOL-1.02

EPL-1.0

EPL-2.0

eCos-2.0

EUPL-3.0

FDK-AAC

LGPL-2.0

LGPL-2.1

LGPL-3.0

MPL-1.1

MPL-2.0

MS-RL

OSL-3.0

QPL-1.0-INRIA-2004

Sendmail-8.23

SimPL-2.0

TAPR-OHL-1.0

TPL-1.0
9.3.5 | Manage license miscompliance issues

Right-click on a row in the inventory table to access the following actions

Change Status. Modify the status of the issue. Values: New, In Progress, Resolved

Change Severity: Modify the severity level of the issue. Values: Critical, High, Medium, Low

Change Assignee: Change the user or identity assigned to address the issue

Copy text to clipboard: Duplicate selected text for easy pasting elsewhere

Copy entire row: Duplicate the entire row of data for easy pasting elsewhere

Copy issue URL: Duplicate the URL associated with the issue, to share or reference the issue

Show/hide rows with the [severity level]: Show/hide rows matching the [severity level] of the selected
row

9.4 | Package Integrity

Package Integrity (also referred to as Package Operational Risk) assesses the operational risk and potential
impact of each package in your codebase by examining package maintainer and popularity factors, and other
relevant metrics. This analysis results in open-source package operational risk severity levels being
categorized into High, Medium and Low. By prioritizing risks based on these categories, you can effectively
focus remediation efforts on the most critical issues.

The Package Integrity issues and findings tables are filtered views of the main issues and findings tables
under Cases & Issues, dedicated solely to issues and findings categorized as package operational risks and
detected during periodic scans.

The following table defines the operational risk metrics used to assess open-source packages.

Metric Property

Maintainer Level: Indicates the level of maintenance based on various

computed factors

— Versions

— Last release

— Last commit
 Metric Property

— Created

— Open issues

— Open pull requests

Popularity Level: Indicates the level of popularity based on various computed

factors

— Weekly downloads

— Number of stars

— Number of forks

— Contributors

Limitation

Package Operational Risk relies on metadata from the package’s associated GitHub repository (such as
activity, popularity, deprecation status). If the package manager entry does not include a valid GitHub
repository URL, operational risk data may be unavailable for that package.

Package Operational Risk policy enforcement

You can create policies to automatically detect and prevent the introduction of operational risks. These
policies ensure that all third-party dependencies align with your organization's security standards and risk
tolerance, helping you maintain a secure software supply chain. For more information about creating policies,
refer to Create Cortex Cloud Application Security policies.

9.4.1 | Package Integrity inventory

The following table describes selected fields in the Package Integrity issues inventory table.

Read more...
 Property Description

Severity Severity level of the package integrity issue (such

as Critical, High, Medium, Low)

Name Name of the package integrity issue

Asset Name Name of the asset affected by the package

integrity issue

Package Manager The package management system used (such as

npm, Maven, pip), in which the package with the
issue was detected

Repository Name of the repository where the package was

obtained

Branch The specific branch of the code where the

package was used

File Path The exact path to the file within the repository's
structure where the issue is located

Data Source The sources from which the issue was generated
or collected

Dependency Type Type of dependency (direct, transitive)

Created Timestamp of when the package integrity issue

was first detected

Status The current state of the issue (New, In Progress,

Resolved)
 Property Description

Backlog Status Indicates whether the issue is classified as pre-

existing technical debt (Backlog) or a newly
introduced risk (New). For more on Backlog status,
refer to Backlog baseline

Assignee The individual or identity responsible for

addressing the package integrity issue

Click on an issue in the table to open a detailed side-card, which provides additional, more in-depth
information about the issue. A concise summary of the issue is displayed at the top of the page. The
information is organized into tabs, including an Overview tab (default display) which provides highlights and a
general summary, while contextual tabs focus on particular details of the issue.

Issue summary

The issue summary, displayed at the top of the card, provides concise details about the issue, including its
name, severity, type (such as configuration or data), the number of days the issue has been open, and the
type of scanner that detected the issue (such as IaC scanner).

NOTE:

You can modify the severity level from the severity field menu.

Overview

The Overview tab provides general details of the package integrity issue:
Description: Provides a summary of the issue

Impact: The potential impact the issue could have on your SDLC

Status: The status of the issue. Values: New, In Progress, Resolved. You can modify the status of the
issue from the menu in the field

Assignee: The entity assigned to resolve the issue. By default the value is Unassigned. Select an
assignee from the menu in the field

Timestamps: Provides the date the issue was created and last updated

Affected Assets: Identifies the asset impacted by the issue. Selecting the asset opens its side panel,
allowing you to view asset details directly without leaving the issue or navigating to the dedicated Assets
section under Inventory

Linked Cases: The cases that the issue is linked to, including the amount of cases, their description and
severity. Selecting a case opens its side panel, allowing you to view case details directly without leaving
the issue or navigating to the dedicated Cases section under Cases & Issues

AppSec Policy: The policy (with its defined rules and conditions) that was triggered, leading to the
creation of this issue. Includes a link to the policy in the general Cortex Cloud Application Security policy
inventory

Evidence: Details and location in the codebase of the package containing the package operational risk
issue
 Issue source and classification

Scanner Type: The type of security analysis tool that identified the package integrity issue

Scanner Source: The specific platform or vendor providing the scanner. Cortex AppSec is
the default source. This field is not selectable

Package Manager: The software package management system used (such as npm, pip,
Maven, NuGet)

Package Registry URL: The URL of the repository or registry from which the package was
sourced. Select the icon next to the policy name to navigate to the package registry

Backlog Status: Indicates if the finding is categorized as Backlog (pre-existing technical

debt) or New (a recently introduced package integrity issue)

AppSec Policy: The Cortex Cloud Application Security policy that was triggered, leading to
the creation of this issue. Select the icon next to the policy name to navigate to the policy in
the the AppSec Policies page. To understand how issues are categorized as backlog/new,
refer to Issue/Finding classification by scanner

Code context

Branch: The specific development branch within the repository containing the package
integrity issue

File Path: The exact location of the relevant file (such as [Link], [Link]) within the
repository's file structure

Commit Hash: The unique identifier of the code change (commit) that is associated with the
package integrity issue

Collaborator: The user that authored the relevant code commit

Commit Time: The date and time when the associated code commit was made

Metadata

Data Source: The system or integration from which the finding data was originally pulled
(such as GitHub or a CI/CD pipeline). Select the icon next to navigate to the data source

Risk Factors: Specific attributes or conditions that contribute to the severity or exploitability
of the package integrity issue

Remediation: Suggested manual remediation steps to address the operational risk. See Actions for more
detailed information

Actions

The Actions tab provides suggested steps to address package operational risk issues.

9.4.2 | Expanded Package Integrity issues inventory information

When you click an issue in the table, a detailed side card opens, providing a concise summary at the top. This
summary includes the issue name, severity level, ID, category (such as Configuration, Vulnerability, Data), the
detecting scanner type, and the age of the issue. The Overview tab then provides in-depth information about
the issue.

Overview
Timestamp: When the issue was created and last updated

Status: The issue status. Values: New, In Progress, Resolved. You can set the status as required

Assignee: The entity assigned to mitigate the issue. You can assign the issue

Description: Provides details about the package integrity issue, including the location where the
package was detected (such as specific repository, file path, and line number) and the operational risks
identified

Impact: The impact that the issue could potentially have on your SDLC

Asset details: Includes Asset (The impacted asset. Clicking on the asset opens the asset side card
without needing to navigate away to the asset section) and Asset Type (The specific asset type in which
the IaC resource was identified)

Evidence: Provides evidence and contextual details within your SDLC containing the package
operational risk:
 Issue source

Data Source: The system or integration from which the issue data was originally pulled
(such as GitHub or a CI/CD pipeline). Click the icon next to the data source to navigate to
the data source itself

Category: Package Operational Risk is the immutable value

AppSec Policy: The violated security standard that led to the creation of the issue. Includes
a link to the policy

Scanning context

Scanner Type: Code. The value is immutable

Scanner Source: Cortex AppSec. The value is immutable

Package Manager: The package manager (such as PIP, npm, Maven) in which the
vulnerability was detected

Package Registry URL: The URL of the package registry (e.g., npm, PyPI, Maven Central)
from which the vulnerable package was obtained

Code location

Repository Name: The name of the version control repository where the issue was located

Branch: The specific branch within the repository containing the issue

File Path: The exact location of the issue within the repository file structure

Commit Hash: The commit hash of the most recent commit that modified the code where
the issue was detected

Commit Time: The timestamp of the most recent commit that modified the code where the
issue was detected

Risk analysis

Risk Factors: Specific attributes or conditions that contribute to an issue's likelihood or the
severity of its impact

Remediation: Suggested mitigation for the package operational risk.

NOTE:

Different issue types include different properties; therefore, not all properties are available for every issue.

Actions

This tab includes suggested steps to fix the issue. No automatic fixes are available for Package Operational
Risks.

War Room

The War Room provides an audit trail of all automatic or manual actions taken on an issue, serving as a
dedicated space to review and interact with your issue. Each issue has a unique War Room. With machine
learning insights, the Cortex Cloud platform suggests the most effective analysts and command sets to help
you address issues efficiently.
9.4.3 | Package Integrity findings

Package Integrity scans produce findings, which are potential package operational risks within your software
packages. These insights help assess and analyze the security posture of your software supply chain.

The Package Integrity Findings table is a filtered instance of the broader Findings table found under Cases &
Issues, meaning it exclusively displays findings categorized as Package Integrity findings.

NOTE:

Findings cannot be mitigated. They must be promoted to issues to enable remediation efforts to secure your
software packages.

To access package integrity findings, navigate to Package Integrity issues (see Package integrity issues), and
click the Findings tab.

The following table describes selected fields in the Package Integrity Findings inventory table.

Read more...

Property Description

Name The name of the package operational risk

Asset Name The asset in which the finding was detected

Finding ID A unique identifier assigned to the finding

Data Source The version control system hosting the repository

which includes the package in which the finding
was detected

Package Manager The package manager hosting the package in

which the finding was detected

Repository The repository hosting the package in which the

finding was detected

Branch The branch in which the finding was detected

 Property Description

File Path The exact path to the file within the repository's
structure where the issue is located

Dependency Type Whether the package is direct or transitive

Created When the finding was first detected

Backlog Status Indicates whether the issue is classified as pre-

existing technical debt (Backlog) or a newly
introduced misconfiguration (New). For more on
Backlog status, refer to Backlog baseline

Expanded Findings details

Click on a finding in the inventory table to open the Findings side card, which provides additional details about
the finding.
 Summary: A summary of the finding at the top of the card including name, id and the type of scanner
(Code is the immutable value for Package Integrity issues) that detected the finding

Description: Provides a summary of the finding

Impact: The potential impact the issue could have on your SDLC

Timestamps: Provides the date the issue was last updated

Affected Assets: Identifies the asset impacted by the finding. Selecting the asset opens its side panel,
allowing you to view asset details directly without leaving the finding or navigating to the dedicated
Assets section under Inventory

Evidence: Details and location in the codebase of the package containing the package operational risk
finding:

Issue source and classification

Package Manager: The dependency management system (such as npm, Maven) used to
include or declare the software component where the finding was detected

Dependency Type: Indicates whether the vulnerability originates from a direct dependency
(explicitly declared in your project) or an indirect/transitive dependency (pulled in by one of
your direct dependencies)

Data Source: The system or integration from which the finding data was originally pulled
(such as GitHub or a CI/CD pipeline). Select the icon next to navigate to the data source

Code context

Repository: The name of the version control repository where the finding was located

Branch: The specific development branch within the repository containing the package
integrity finding

First Hash: The commit hash of the earliest code change where this finding was identified

First Commit Date: The date of the commit that introduced the problematic code or
dependency into the repository. This helps understand how long an issue has existed and
for prioritizing remediation efforts based on its age

Collaborator: The user that authored the relevant code commit

Code: The file and code including the license miscompliance in which the finding was detected

Scan Metadata

Run ID: The unique identifier of the specific scan execution during which this finding was
detected

9.4.4 | Manage Package Integrity issues

Right-click on a row in the inventory table to access the following actions

 Change Status. Modify the status of the issue. Values: New, In Progress, Resolved

Change Severity: Modify the severity level of the issue. Values: Critical, High, Medium, Low

Change Assignee: Change the user or identity assigned to address the issue

Copy text to clipboard: Duplicate selected text for easy pasting elsewhere

Copy entire row: Duplicate the entire row of data for easy pasting elsewhere

Copy issue URL: Duplicate the URL associated with the issue, to share or reference the issue

Show/hide rows with the [severity level]: Show/hide rows matching the [severity level] of the selected
row

10 | Application Security scans management

Abstract

10.1 | Overview
You can manage Cortex Cloud Application Security scans through dedicated periodic branch and pull
request (PR) scans inventories, which provide a central view of scan health, status, scope, and detected
issues. This enables efficient tracking, analysis, and management of scans for vulnerability insights

In addition, you can configure native scanners, optimize settings, and monitor scan health to streamline your
scan management process and enhance your security posture.

How to access Cortex Cloud Application Security scan management

To access scan management:

1. Under Modules, select Application Security.

2. Under Scans, select a scan type:

Branch Periodic Scanning: Scans code branches on a schedule to identify vulnerabilities early in
development. For more information about branch periodic scans, refer to Branch periodic scans

Pull Request Scans: Scans code changes within pull requests to prevent the introduction of new
vulnerabilities. For more information about pull request scans, refer to Pull Request scans

Scan data presentation

Periodic and pull request scan details are presented on the Cortex Cloud console across three levels of
granularity: an inventory table providing a list of scans, a side panel providing general scan details including a
high-level breakdown of the findings and issues detected during the scan, and an expanded description card,
providing detailed information about the issues generated from these scans.

NOTE:
 While scans provide a comprehensive inventory of all issues detected during a scan, dedicated inventories
are also maintained for specific scan types for more granular management. For more information, refer to
Infrastructure as Code (IaC) scanners, Secrets scanners and Software Composition Analysis (SCA )
scanners.

10.2 | Branch periodic scans

Branch periodic scans are automated checks that assess the security posture of applications and
infrastructure. These scans run at regular intervals using supported Cortex Cloud Application Security
scanners to identify vulnerabilities and weaknesses. You can analyze the scans directly from a dedicated
inventory table, which displays branch periodic scan details, including code context, scan date, health,
detected findings, and generated issues.

How to access branch periodic scans

Under Modules select Application Security → Branch Periodic Scanning (under Scans).

Branch periodic scan inventory

The branch periodic scan inventory displays the following details:

The following fields are displayed in the scan inventory table.

Repository: Identifies the scanned repositories

Organization: Specifies the organization owning the repository

Scanned Branch: Indicates the branch analyzed during the scan

Scan Date: Records the timestamp of the last scan execution

Scan Health: Displays the health of the scan. Values include:

Error

Partially: Indicates that the scan execution resulted in a partial completion, with some scan
modules (for example IaC) succeeding and others (such as Secrets) failing

Completed

NOTE:

The inventory table displays scan issues for visibility only; remediation is not available here. To resolve
issues, navigate to the dedicated issue type inventory, where you can manage and remediate them.

Expanded periodic scan details

Selecting a scan from the inventory opens its side car, which displays a general overview of the scan's details
and provides access to details of issues and findings via dedicated scan type tabs.

Overview

The overview tab displays these scan details.

 General scan information

Organization: The specific business entity or organizational unit associated with the periodic scan

Scan Date: The date and time when the periodic scan was performed

Scan Health: The overall health status of the periodic scan, indicating its success, failure, or other
relevant states

Code context

Repository: The version control repository that was scanned

Scanned Branch: The specific branch within the repository that was subjected to the periodic
scan

Scan results summary

Issues: A breakdown by severity and count of actionable security issues identified from the scan's
findings

Issues by Type: A categorization and count of identified issues based on their specific
vulnerability types (such as IaC, Secrets)

Findings: A breakdown by severity and count of findings discovered by the scan before being
converted into actionable issues

Findings by Type: A categorization and count of raw findings based on their specific detection
types.

Vulnerabilities

When selecting the Vulnerabilities tab, the Issues tab is displayed by default. Selecting an issue in the table
that is presented then opens its side card directly within Scans Management, eliminating the need to navigate
to the dedicated Vulnerabilities issues page.

For detailed information about vulnerabilities issues, refer to Software Composition Analysis (SCA) vulnerability
issues.

Select the Findings tab to open a list of findings associated with the issue, including the name of the finding,
the asset in which the finding was detected, and the repository hosting the asset.

Click on a finding for additional details, including a description of the finding the asset type and group
associated with the finding, when last updated, and evidence for the finding.

Select the Findings tab to open a list of findings associated with the issue, including the name of the finding,
the asset in which the finding was detected, and the repository hosting the asset.

Click on a finding for additional details, including a description of the finding the asset type and group
associated with the finding, when last updated, and evidence for the finding.

Configurations

When selecting the Configurations tab, the Issues tab is displayed by default. Selecting an issue in the table
that is presented then opens its side card directly within Scans Management, eliminating the need to navigate
to the dedicated IaC misconfigurations issues page.
For detailed information about IaC misconfiguration issues, refer to Overview.

Select the Findings tab to open a list of findings associated with the issue, including the name of the finding,
the asset in which the finding was detected, and the repository hosting the asset.

Click on a finding for additional details, including a description of the finding the asset type and group
associated with the finding, when last updated, and evidence for the finding.

Secrets

When selecting the Secrets tab, the Issues tab is displayed by default. Selecting an issue in the table that is
presented then opens its side card directly within Scans Management, eliminating the need to navigate to the
dedicated Secrets issues page.

For detailed information about Secrets issues, refer to Secrets issues.

Select the Findings tab to open a list of findings associated with the issue, including the name of the finding,
the asset in which the finding was detected, and the repository hosting the asset.

Click on a finding for additional details, including a description of the finding the asset type and group
associated with the finding, when last updated, and evidence for the finding.

Package Integrity

When selecting the Package Integrity tab, the Issues tab is displayed by default, displaying a list of package
operational risk and license issues, with detailed properties for each entry. Selecting an entry then opens its
side card directly within Scans Management, eliminating the need to navigate to the dedicated Package
Integrity issues page.

For detailed information about Package Integrity issues, refer to Package Integrity.

Select the Findings tab to open a list of findings associated with the issue, including the name of the finding,
the asset in which the finding was detected, and the repository hosting the asset.

Click on a finding for additional details, including a description of the finding the asset type and group
associated with the finding, when last updated, and evidence for the finding.

10.3 | Pull Request scans

Pull Request (PR) scans are initiated by events triggered by version control systems such as GitHub, GitLab,
Bitbucket and Azure Repos, or via webhooks. These scans are run on default or non-default branches
containing open PRs or Merge Requests (MR) from your integrated repositories.

The system executes scans based on the following logic:

Initial Scan (PR/MR Open): When a new PR or MR is opened, the system performs a full scan of all files
included in the request

Subsequent Scan (New Commits): For any new commit pushed to an existing open PR/MR, the system
executes a delta analysis (diff scan). This focused scan analyzes only the modified files, which prevents
redundant findings. The PR comments are updated according to the results of the latest commit scan

Scan results are based on default enforcement thresholds. You can analyze PR scans directly from the
dedicated inventory table, which displays detailed metrics including code context, scan date, health, status,
detected findings, and generated issues.

How to access Pull Request scans

Under Modules select Application Security → Pull Request Scans (under Scans).

Pull Request scan inventory

The pull request scan inventory displays the following details:

Repository: Identifies the scanned repositories

Organization: Specifies the organization owning the repository

Scanned Branch: Indicates the branch analyzed during the scan

Scan Date: Records the timestamp of the last scan execution

Pull Request ID: The unique identifier of the PR

Commit: The commit included in the PR

Scan Health: Displays the health of the scan. Values include:

Error

Partially: Indicates that the scan execution resulted in a partial completion, with some scan
modules (for example IaC) succeeding and others (such as Secrets) failing

Completed

PR Status: Status of the PR scan. Values: "Passed', 'Blocked', 'In Progress'

NOTE:

The inventory table displays scan issues for visibility only; remediation is not available here. To resolve
issues, navigate to the dedicated issue type inventory, where you can manage and remediate them.

Expanded Pull Request scan details

Selecting a scan from the inventory opens its side car, which displays a general overview of the scan's details
and provides access to details of issues and findings via dedicated scan type tabs.

Overview

The overview tab displays these scan details.

 General scan information

Organization: The specific business entity or organizational unit associated with the periodic scan

Scan Date: The date and time when the periodic scan was performed

Scan Health: The overall health status of the periodic scan, indicating its success, failure, or other
relevant states

Code context

Repository: The version control repository that was scanned

Scanned Branch: The specific branch within the repository that was subjected to the periodic
scan

Scan results summary

Issues: A breakdown by severity and count of actionable security issues identified from the scan's
findings

Issues by Type: A categorization and count of identified issues based on their specific
vulnerability types (such as IaC, Secrets)

Findings: A breakdown by severity and count of findings discovered by the scan before being
converted into actionable issues

Findings by Type: A categorization and count of raw findings based on their specific detection
types.

Vulnerabilities

Selecting the Vulnerabilities tab, the Issues tab is displayed by default. Selecting an entry then opens its side
card (which includes remediation options) directly within Scans Management, eliminating the need to navigate
to the dedicated Vulnerabilities issues page.

For detailed information about vulnerabilities issues, refer to Software Composition Analysis (SCA) vulnerability
issues.

Select the Findings tab to open a list of findings associated with the issue, including the name of the finding,
the asset in which the finding was detected, and the repository hosting the asset.

Click on a finding for additional details, including a description of the finding the asset type and group
associated with the finding, when last updated, and evidence for the finding.

Configurations

When selecting the Configurations tab, the Issues tab is displayed by default. Selecting an issue in the table
that is presented then opens its side card directly within Scans Management, eliminating the need to navigate
to the dedicated IaC misconfigurations issues page.

For detailed information about IaC misconfiguration issues, refer to Overview.

Select the Findings tab to open a list of findings associated with the issue, including the name of the finding,
the asset in which the finding was detected, and the repository hosting the asset.
Click on a finding for additional details, including a description of the finding the asset type and group
associated with the finding, when last updated, and evidence for the finding.

Secrets

When selecting the Secrets tab, the Issues tab is displayed by default. Selecting an issue in the table that is
presented then opens its side card directly within Scans Management, eliminating the need to navigate to the
dedicated Secrets issues page.

For detailed information about Secrets issues, refer to Secrets issues.

Select the Findings tab to open a list of findings associated with the issue, including the name of the finding,
the asset in which the finding was detected, and the repository hosting the asset.

Click on a finding for additional details, including a description of the finding the asset type and group
associated with the finding, when last updated, and evidence for the finding.

Package Integrity

When selecting the Package Integrity tab, the Issues tab is displayed by default, displaying a list of package
operational risk and license issues, with detailed properties for each entry. Selecting an entry then opens its
side card directly within Scans Management, eliminating the need to navigate to the dedicated Package
Integrity issues page.

For detailed information about Package Integrity issues, refer to Package Integrity.

Select the Findings tab to open a list of findings associated with the issue, including the name of the finding,
the asset in which the finding was detected, and the repository hosting the asset.

Click on a finding for additional details, including a description of the finding the asset type and group
associated with the finding, when last updated, and evidence for the finding.

10.4 | CI scans
CI scans detect exposed secrets, misconfigurations in your infrastructure-as-code (IaC) files, vulnerabilities in
your software composition analysis (SCA) packages, and license non-compliance in your CI pipelines. Scan
results, including details of the scan, scan scan status and health, are displayed in a dedicated table. For
deeper analysis, click on a scan in the table to open a side panel containing general scan details and a
breakdown of CI findings and issues.

How to access CI scans

Under Modules select Application Security → CI Scans (under Scans).

CI scan inventory table

The CI scan inventory table displays the following details:

 Property Description

Repository The scanned repository

Organization The organization owning the repository

Scanned Branch Indicates the branch analyzed during the scan

Scan Date Records the timestamp of the last scan execution

Scan Health Displays the health of the scan. Values include:

Completed

Partially: Indicates that the scan execution

resulted in a partial completion, with some
scan modules (for example IaC) succeeding
and others (such as Secrets) failing

Error

CI Status Displays the health status of the scan. Values:

Passed, Blocked, In Progress

NOTE:

The inventory table displays scan issues for visibility only; remediation is not available in scan management.
To resolve issues, navigate to the dedicated issue type inventory, where you can manage and remediate
them.

Expanded CI scan details

Selecting a scan from the inventory opens its side car, which displays a general overview of the scan's details
and provides access to details of issues and findings via dedicated scan type tabs.

Overview

The overview tab displays these scan details.

 General scan information

Organization: The specific business entity or organizational unit associated with the periodic scan

Scan Date: The date and time when the periodic scan was performed

Scan Health: The overall health status of the periodic scan, indicating its success, failure, or other
relevant states

Code context

Repository: The version control repository that was scanned

Scanned Branch: The specific branch within the repository that was subjected to the periodic
scan

Scan results summary

Issues: A breakdown by severity and count of actionable security issues identified from the scan's
findings

Issues by Type: A categorization and count of identified issues based on their specific
vulnerability types (such as IaC, Secrets)

Findings: A breakdown by severity and count of findings discovered by the scan before being
converted into actionable issues

Findings by Type: A categorization and count of raw findings based on their specific detection
types.

Vulnerabilities

When selecting the Vulnerabilities tab, the Issues tab is displayed by default. Selecting an issue in the table
that is presented then opens its side card directly within Scans Management, eliminating the need to navigate
to the dedicated Vulnerabilities issues page.

For detailed information about vulnerabilities issues, refer to Software Composition Analysis (SCA) vulnerability
issues.

Select the Findings tab to open a list of findings associated with the issue, including the name of the finding,
the asset in which the finding was detected, and the repository hosting the asset.

Click on a finding for additional details, including a description of the finding the asset type and group
associated with the finding, when last updated, and evidence for the finding.

Configurations

When selecting the Configurations tab, the Issues tab is displayed by default. Selecting an issue in the table
that is presented then opens its side card directly within Scans Management, eliminating the need to navigate
to the dedicated IaC misconfigurations issues page.

For detailed information about IaC misconfiguration issues, refer to Overview.

Select the Findings tab to open a list of findings associated with the issue, including the name of the finding,
the asset in which the finding was detected, and the repository hosting the asset.
Click on a finding for additional details, including a description of the finding the asset type and group
associated with the finding, when last updated, and evidence for the finding.

Secrets

When selecting the Secrets tab, the Issues tab is displayed by default. Selecting an issue in the table that is
presented then opens its side card directly within Scans Management, eliminating the need to navigate to the
dedicated Secrets issues page.

For detailed information about Secrets issues, refer to Secrets issues.

Select the Findings tab to open a list of findings associated with the issue, including the name of the finding,
the asset in which the finding was detected, and the repository hosting the asset.

Click on a finding for additional details, including a description of the finding the asset type and group
associated with the finding, when last updated, and evidence for the finding.

Package Integrity

When selecting the Package Integrity tab, the Issues tab is displayed by default, displaying a list of package
operational risk and license issues, with detailed properties for each entry. Selecting an entry then opens its
side card directly within Scans Management, eliminating the need to navigate to the dedicated Package
Integrity issues page.

For detailed information about Package Integrity issues, refer to Package Integrity.

Select the Findings tab to open a list of findings associated with the issue, including the name of the finding,
the asset in which the finding was detected, and the repository hosting the asset.

Click on a finding for additional details, including a description of the finding the asset type and group
associated with the finding, when last updated, and evidence for the finding.

10.5 | Manage repository scan configurations

You can achieve granular control over repository security through scan configurations. Tailor scans by
managing branches, enabling/disabling scanners, customizing PR behavior, excluding paths, and managing
repository deletion.

To access repository scan configurations:

1. Select Settings → Data Sources → hover over a connected data source from the catalog → click View
Details.

2. Select an instance.

3. Right-click on a selected repository(ies) → Scan Configuration.

4. Configure scan settings:

 Configure scanners:

Enable or disable Code Security scanners (IaC, SCA, Secrets)

Enable or disable Git history scans to automatically detect secrets still present in a
repository’s past commits. By identifying these exposed credentials, you can proactively
address risks and prevent potential data breaches

Enable/disable secrets validation to check a detected secret’s activity status via public APIs.
This allows you to prioritize and address only active, exposed secrets.

PR scans:

Scan PR: Enable security scans to automatically trigger on a pull request (PR) to identify
potential security risks or misconfigurations before the code is merged

Fail PR on scan error: Enable pull requests (PRs) to automatically fail on a scan error. This
prevents security risks and misconfigurations from being merged

Tagging Bot

Exclude paths: Specify the files and directories to exclude from scanning.

Exclude directories: Enter folder names to exclude all files inside, such as
node_modules/, tests/, dist/

Exclude files by pattern: Use wildcards: * for any number of characters, ? for a single
character

.*.log: Excludes all log files

*.[Link] Excludes all minified JavaScript files

Use a Comma-Separated List: Separate multiple exclusions with commas. For example,
node_modules/, dist/, docs/)

Avoid leading slashes: Use dist/, not /dist/

5. Click Save.

Configure active scanners

Enable or disable specific scanners. Options: IaC, Secrets.

NOTE:

For Secrets scans you configure these additional settings:

Git history scan: scans Git history to detect secrets deleted from files but still present in past commits,
notifying you of these exposures. This helps mitigate the risk of compromised credentials that may be
found in the repository's history

Secret validation: validates detected secrets against public APIs to verify their active status, enabling
you to prioritize and promptly address exposures. Secrets validation scanning is available through the
Cortex Cloud tenant and IDE extensions
Configure pull request (PR) scanning

Control your pull request security by enabling scans and configuring error handling. You can perform the
following actions:

Scan PR: When enabled, security scans are performed on pull requests (PRs) before merging

Fail PR on scan error: When enabled, any scanner error during a pull request (PR) check will result in
the PR failing and being blocked from merging

Configure excluded paths

By default, Cortex Cloud Application Security scans all paths in all repositories. You can define rules to
exclude paths and apply them to selected repositories. This improves scan performance and helps focus on
critical areas by ignoring irrelevant or temporary files.

To exclude paths from scans, list a path or multiple paths or files separated by commas (,) and then select the
repositories where these exclusions should apply.

10.6 | Monitor data source instances health

You can monitor the health and status of your integrated data source instances and their repositories. Tracking
and analyzing this data allows you to understand and troubleshoot errors, mitigate detected vulnerabilities,
and ensure the reliability of your data sources.

How to view scans health

1. Navigate to Settings → Data Sources (under Data Collection).

2. Search for data instance such as GitHub (Code Scanning), in the search bar.

The data source is displayed, including the number of connected instances and the instance status.
Status options include Connected, Error, Warning.

3. Hover over the data source and select View Details to display the list of data source instances.

4. Select a data source instance.

The health status page opens, displaying:

The status of the instance, connected repositories and instance type, such as cloud are displayed
on the top card

A list of repositories connected to the instance, including scan details such as status, scan
coverage (connected scanners such as SCA, Secrets and IaC and the scan status), location
(scanned branch, organization, repository) and timestamp
Understanding errors and warnings

An error status is displayed if:

More than 50% of the repositories associated with the instance have errors

There is a token error for a repository

There are missing permissions (categorized as an error based on severity)

Webhook subscription errors (categorized as an error based on severity)

At least one repository includes a warning

A warning status is displayed if:

Less than 50% of the repositories associated with the instance have errors

Missing permissions (categorized as a warning based on severity)

Webhook subscription errors (categorized as a warning based on severity)

Troubleshoot scan health

You can troubleshoot both instance and repository issues.

1. Select an instance containing an error or warning status.

2. Review instance issues: click Review Health in the top bar.

A list of errors by repository and related to the instance are displayed. The list includes these unique
properties:

Classification: Options: Warning or Error

Error Type: The type of instance error. Options: Permission, Clone, Connection, Webhook
subscription, Token

Repository: the repository containing the issue

Scope: the scope of the issue

3. Review repository issues: select a repository in the table with a status of Error or Warning.

A list of repository-related warnings and errors is displayed, including details such as description, type,
location, and timestamp.

11 | Application Security Policies

Abstract

AppSec policies define threat responses by setting conditions, scope, and actions. Use out-of-the-box
policies or clone them to create custom ones.
A Cortex Cloud Application Security policy defines how a system should respond to application security
threats. It includes conditions that trigger the policy, the scope of its application, and the actions to be taken
when these conditions are met. When a policy detects a threat, it generates an issue for remediation.

Cortex Cloud Application Security provides out-of-the-box policies. In addition, you can create custom policies
to tailor it to your specific business or infrastructure requirements. Out-of-the-box policies cannot be modified
directly. However, you can create a custom policy by cloning the existing one. This allows you to make
changes to the original policy according to your requirements. Refer to Manage Cortex Cloud Application
Security policies for more information.

11.1 | User roles and permissions

These user roles and permissions are required for AppSec policies:

Roles with Policies View/Edit permissions can create and modify detection policies

Roles with Policies Read permissions can view detection policies

An AppSec Admins user role has View/Edit permissions

A DevSecOps user role only has View permissions

11.2 | Policies inventory

The Cortex Cloud Application Security policies inventory includes both out-of-the-box and custom policies.

To access Cortex Cloud Application Security polices, under Modules, select Cortex Cloud Application Security
→ AppSec Policies (under Policy Management).
The following list describes the policy properties exposed by default in the inventory table. Additional
properties can be added to the table from the Table Settings Menu.

Field/Attribute Description

Policy Name The name of the Cortex Cloud Application Security

policy

Status Whether the policy is enabled or disabled.

Disabled policies are greyed out but remain
clickable, allowing you to open the policy side
panel

Description A description of the Cortex Cloud Application

Security policy
 Field/Attribute Description

Conditions The specific criteria used to determine when policy

actions are applied

Actions The steps taken when the policy conditions and

scope are met

Scope The type of assets to be evaluated by the policy.

See for more information about policy scope

Trigger Trigger types that define when the condition will be

evaluated. Options include Periodic scan, Pull
Request scan and CI scan

Last Triggered The last time that the policy was triggered

Created By The user or entity that created the policy

Modified by The user or entity that modified the policy

Modification Time The timestamp of the most recent change to the

policy

Open Issues The amount of issues detected by the policy that

remain unresolved

Expanded policy details

Selecting a policy opens a side panel where you can review additional details:
 Metadata:

Policy details: Name and description of the policy

Policy ownership: Information on the policy's creator and last modifier

NOTE:

To view all out-of-the-box (OOTB) policies, filter by Policy Owner = System.

Timestamps: The last time the policy was modified and last triggered

Scope: The asset type the policy applies to, along with a table summarizing the policy conditions,
trigger, and actions, displayed as follows:

When: The trigger that initiates the policy action, such as Periodic, Pull Request, or CI scans

If: Conditions that are applied to the policy. For example: (Finding Type = IaC
Misconfiguration) AND (Severity = Critical)

Then: Triggered actions for the policy, such as Create issue and Block PR

11.3 | Create Cortex Cloud Application Security policies

You can create custom policies to detect and prevent security risks across your software development
environments and workflows. Cortex Cloud Application Security policies define how to respond to code and
configuration findings—either by blocking risks (prevent) or creating issues for remediation (detect). They help
enforce consistent, automated responses to threats across your code and CI/CD environments before they
reach production.

Cortex Cloud Application Security are categorized into two types based on their focus:

Code Security policies

CI/CD Configuration policies

11.3.1 | Create code security policies

Code policies automatically prevent and detect security risks across your code-to-cloud workflow, ensuring
threats are stopped before they reach production. They address secrets, CVE vulnerabilities, IaC
misconfigurations, code weaknesses, and package-related risks—including operational risks and license
violations. These policies support results from third-party scanners and apply to periodic scans, pull requests,
and CI-triggered scans.

Prioritize risk with context

To ensure security efforts are focused and effective, you can integrate contextual information into your
policies:
 Code-to-cloud context: Create policies to prioritize and act on issues that pose the greatest security risk
to deployed production assets

Application context: Align Scope-Based Access Control (SBAC) policies with an application-specific
purpose and business sensitivity to ensure relevant and effective security enforcement across its
lifecycle. For more information about creating application-scoped policies, refer to Scope user access to
applications (Application SBAC)

Using runtime and application contexts focuses efforts on high-impact issues and reduce noise.

1. Under Modules, select Application Security → AppSec Policies.

2. Click Add Policy.

3. On the General step of the policy creation wizard.

a. Provide a unique policy name (required) and description.

b. Select Code Scanners (default) as the policy type to define prevention and detection rules for
code-related security risks.

c. Click Next.

4. On the Conditions step of the wizard, select Add Filters to define the conditions that apply to the policy.
By default, the Finding Type field is displayed.

a. Finding Type (required): Select the Finding Type (scanner). The policy will only evaluate findings
generated by the selected scanner(s).

Scanner options include: Select All, Vulnerability, Secrets, IaC Misconfiguration, License,
Operational Risk, Code Weakness.

Considerations:

You can select multiple finding types (scanners) to broaden the policy's coverage, allowing
it to apply to multiple security categories simultaneously. By default multiple scanners are
selected, limiting the available filters

Selecting the specific scanner types specializes the policy, determining the specific
category of security risk it monitors (such as Secrets). This selection also unlocks the
filtering attributes unique to the scanner, which become available on the Conditions screen

b. Click AND to select an attribute to filter the findings for the selected Finding Type (scanner).

When applying filters to the selected finding types, the system's logic adapts based on the
attributes you choose, creating a tailored policy that targets the specific risk patterns you are
looking for.

Filter logic:

Using AND and OR operators allows you to broaden policy coverage while maintaining dedicated
logic for each Finding Type, giving precise control over how different conditions are evaluated.
 AND logic within a bracket: All conditions in a single bracket must be met for the policy
action to apply

OR logic between brackets: Multiple brackets can be combined with the OR operator to
define separate evaluation rules for different sets of conditions

Example 1. Example

In this example, the policy applies to findings that meet the first set of conditions (Secrets with
Critical severity) or the second set (IaC with High severity).

[Finding Type = Secrets AND Severity = Critical]

OR
[Finding Type = IaC AND Severity = High]

c. Select a value for the filter.

d. Click Next.
NOTE:

For a detailed list of all available attributes and their values by scanner type, refer to Cortex Cloud
Application Security code policy Condition attributes .

5. On the Scope step of the wizard: Define the scope of the assets to be evaluated by the policy using one
of these methods: Asset Types or Asset Groups.

a. If selecting Asset Types:

i. An unfiltered list of Cortex Cloud Application Security assets in the inventory is displayed.

ii. Narrow the scope of the assets to be checked by the policy: Select Add Filter → [Filter
type] → [Filter value].

You can filter assets by:

 Category. Values: Application, Repository.

Application context: If you select Business Applications as the type of Category, a list
of business applications is displayed, and the policy is scoped to evaluates these
applications. You can narrow the scope of the policy to specific applications by
applying additional filters, such as Business Application Names.

Business Application Names. Value: String

Business Application Criticality. Values: Select All, Critical, High, Medium, Low

Application Business Owner. Values: String

Repository Name: Values: String

Repository ID: Values: String

Is Public Repository: Values: Select All, Yes, No

Has Deployed Assets (Runtime context): Values: Select All, Yes, No

Has Internet-exposed deployed assets (Runtime context): Values: Select All, Yes, No

Has deployed assets with access to sensitive data (Runtime context): Values: Select
All, Yes, No

Has deployed assets with privileged capabilities (Runtime context): Values: Select All,
Yes, No

Provider: Values: AWS Code Build, AWS Code Commit, Azure Repos, Bitbucket,
Bitbucket Data Center, Circle CI, Cortex CLI, GiHub, GitHub Actions, GitLab, GitLab
Self-Managed, HCP Terraform Tasks, HCP Terraform Enterprise Run Tasks, Jenkins

NOTE:

SBAC scope-based limitations do not apply to Asset Types

b. If selecting Asset Groups: Select the asset groups against which this policy and its chosen
detection rules will be evaluated. You can only select asset groups that you are assigned to you
as part of your scope.

Application context (SBAC): For more information about Cortex Cloud Application Security Asset
Groups, refer to SBAC Scope-based access control for Cortex Cloud Application Security.

NOTE:

When selecting Asset Groups, the code policy is evaluated only on the application and
repository assets included in the group.

c. Click Next.
NOTE:

For each application that matches the criteria, the policy is evaluated only on the repositories
associated with that application.

6. On the Triggers & Action step of the wizard.

a. Select one or more trigger types that define when the condition will be evaluated. You must select
at least one trigger.
 Periodic Scan: Automated security scans that run every 12 hours

PR (Pull Request)Scan: Security scans triggered automatically by events in your version

control system when a Pull Request (PR) or Merge Request (MR) is created or updated

CI Scan: Security scans that run as part of your build pipeline, including checks on your
code and configurations.

NOTE:

If you select only Code Weaknesses as the Finding Type in the condition step (indicating a third-
party scanner), the PR and CI triggers are disabled, leaving only Periodic Scan enabled.

b. Specify which actions to take when the policy detects its target risk. You must select at least one
action for each selected trigger.

Periodic Scan PR Scan CI Scan

Create an issue Block PR Block CI

(required)
PR Comment CLI Report
Override Severity
Create an issue Create an issue

Override Severity Override Severity

Table Legend

Create an issue: Create an issue if policy conditions within the selected scope are met. You
can control when an issue is created—for example, during periodic scans but not in pull
request scans. You can also assign different severities based on the trigger, allowing lower
severity for issues detected after a block compared to those found during periodic scans

Block: Block a run if the policy conditions within the selected scope are met

PR Comment: Automatically posts a comment on a pull request when the policy conditions
for the selected trigger are met

CLI Report: Enable reporting via CLI if policy conditions within the selected scope are met.
Available when CI scan is selected as the evaluation method

Override Severity: Manually override the default severity that the system assigns to the issue

c. Click Next.

7. On the Summary step of the wizard: Review the policy settings and click Apply.

This step provides an overview of the configured policy, including its name and description, the
configured scope, and a table of conditions, triggers, and actions. The table splits conditions by trigger,
since not all selected triggers apply to all selected Finding Types—for example, Code Weaknesses. It
also displays the user who created the policy and the creation date.
 You can view the custom policy that you created in the general policies table on the AppSec Policies
page.

[Link] | Cortex Cloud Application Security code policy Condition attributes

Abstract

Learn about Application Security code policy Condition filters and attributes.

Condition attributes are data fields used to filter findings. The list includes common attributes - including the
Finding Type attribute - as well as scanner-specific attributes, which are displayed after you select a scanner
as the Finding Type. You can select multiple attributes, from both common and scanner-specific lists, to create
precise filters and target policies more effectively.

Common Condition attributes

Severity. Values: Select All, Critical, High, Medium, Low

Backlog Status. Values: Select All, Backlog, New

For more information about Backlog Status, refer to Backlog baseline

Respect Developer Suppression. Values: Select All, Yes, No. For more information on developer
suppressions, see Developer Suppressions below

Category. The top-level domain for organizing security findings. Values: Configuration, Vulnerability,
Malware, Identity, Data, Code, Posture, Brand Protection

Finding Type: See below for detailed information

Finding Type-specific attributes (scanner-specific)

The Finding Type filter allows you to select the scan types that the policy will apply to. Multiple selection is
supported.

Finding Type properties include: Select All, Secrets, IaC Misconfigurations, Vulnerabilities, Licenses,
Operational Risk and Code Weaknesses

After selecting Finding Type as the filter, you can further refine the policy criteria by selecting specific
attributes of the finding type using the AND operator.

Example 2. Example

When License is selected as the finding type, these following package attributes are available for filtering:
License Type, Package Deprecated, Package Maintained, Package Operational Risk and Package Popularity.
If you select License Type, a list of selectable licenses (such as Artistic 2.0, APSL) are displayed.

The following table describes the scanner type attributes.

 Attribute Description

Secrets Severity

Logic: Equal to, greater than, less than

Severity level: Critical, High, Medium,

Low

AppSec Rule

Logic: Is, Is not

Rules: Multi-selection list of available

detection rules or type-in field

Secret Validity

Logic: Is, Is not

Values: Privileged, Valid, Invalid,

Unknown

AppSec Rule Labels

Logic: Is, Is not

Labels: Multi-selection list of available

labels
 Attribute Description

IaC misconfiguration Has an automated fix:

Logic: Is, Is not

Values: Select All, Yes, No

AppSec Rule

Logic: Is, Is not

Rules: Multi-selection list of available

detection rules

IaC tag

Logic: Is, Is not

Tags: [One or more tags, separated by

commas or spaces]

AppSec Rule Labels

Logic: Is, Is not

Labels: [Multi-selection list of available

labels or type-in field]
 Attribute Description

Vulnerabilities Risk Factors

Logic: Is, Is not

Values: Critical severity, High severity,

Medium severity, Has fix, Remote
execution, DoS-Low, DoS-High, Recent
vulnerability, Exploit exists in the wild,
Exploit exists -POC, Attack complexity:
low, Attack vector: network

CVE ID

Logic: Is, Is not

CVE IDs: [Multiple CVE IDs can be

entered, separated by commas or
spaces]

CVE Fix Available Date: Range: Select a start

and end date

CVE Publish Date: Range: Select a start and

end time

CVSS Score

Logic: Is equal to, is not equal to, is

equal or greater than, is equal or less
than

Score: Number between 0-10

EPSS

Logic: Is equal to, is not equal to, is

equal or greater than, is equal or less
than

Number between 0.00–1.00

Has a fix:

Logic: Is, Is not

Values: Select All, Yes, No

Is KEV

Logic: Is, Is not

Values: Select All, Yes, No

Attribute Description

Package Name

Logic: Is, Is not, Contains, Does not

contain

Package Name: [Package name

string]

Package Deprecated

Logic: Is, Is not

Values: Select All, Yes, No

Package Maintained

Logic: Is, Is not

Values: Infrequently Maintained,

Moderately Maintained, Frequently
Maintained

Package Popularity

Logic: Is, Is not

Values: Select All, Low, Medium, High

Package Operational Risk

Logic: Is, Is not

Values: Select All, Low, Medium, High

Package Version

Logic: Equal to, not equal to, greater

than, less than

Version: [Package version string]

 Attribute Description

License License Type

Logic: Is, Is not

Licenses: Multi-selection list of

available license types

AppSec Rule: See above

AppSec Rule Label: See above

Package Deprecated: See above

Package Maintained: See above

Package Name: See above

Package Operational Risk: See above

Package Popularity: See above

Package Version: See above

Operational risk Popularity: See Package Popularity above

Maintained: See Package Maintained above

Deprecated: See Package Deprecated

above

Package Name: See above

Package Version: See above

 Attribute Description

Code Weaknesses CWE:

Logic: Contains, does not contain,

equals, does not equal

Values: [CWE ID (text string)]

Language:

Logic: Contains, does not contain,

equals, does not equal

Values: [Supported program language,

such as Java (text string)]

OWASP Category:

Logic: Contains, does not contain,

equals, does not equal

Values: [Top 10 OWASP CWE

categories (text string)]

Source:

Logic: Contains, does not contain,

equals, does not equal

Values: [Text string]

Developer Suppressions

Apply developer suppressions through the Respect Developer Suppression attribute. Options: Select All, Yes,
No.

No: If you do not select the Respect Developer Suppressions attribute, no additional action is taken, and
developer suppressions are not considered in the policy

Yes: If you select the Respect Developer Suppressions attribute, a new condition is automatically added
to each existing condition group, ensuring the policy respects developer suppressions

Precedence rule: If both a global suppression setting and a condition-level filter for Respect Developer
Suppression are present, the condition-level filter will always take precedence during policy evaluation.

Build queries with Finding Types

You can select the Finding Type attribute at the beginning of a new query and also after each OR operator.
When an AND operator follows a selected Finding Type, the available attributes for filtering will be limited to
those relevant to that specific Finding Type. The OR operator, however, provides access to all available
attribute options.
Example 3. Example

finding type = Vulnerabilities AND CVSS>9 AND has a fix = true) OR (finding type
= Operational Risk AND maintenance = LOW) OR (finding type = IaC misconfiguration
AND IaC tag = kuku

11.3.2 | Create CI/CD configuration policies

CI/CD configuration policies scan your CI/CD and Version Control System (VCS) environments to detect and
enforce standards against misconfigurations and risky settings in pipelines, workflows and VCS systems (such
as GitHub).

Prioritize risk with application context: By leveraging application context, you can create Scope-Based Access
Control (SBAC) policies that align security enforcement with each application's purpose, business sensitivity,
and lifecycle, ensuring targeted and effective risk management that allows you to focus efforts on high-impact
issues and reduces noise. For more information about creating application-scoped policies, refer to Scope
user access to applications (Application SBAC)

1. Under Modules, select Application Security → AppSec Policies.

2. Click Add Policy.

3. On the General step of the policy creation wizard.

a. Provide a policy name (required) and description.

b. Select CI/CD Configuration Scanners as the policy type.

c. Click Next.

4. On the Conditions step of the wizard, define the conditions that apply to the policy.

a. Ensure CI/CD Risk is selected as the Finding Type. This is the only available option and is
selected by default.

b. Click AND to define CI/CD Risk attributes.

Adding attributes allows you to narrow and refine the findings from the CI/CD Risk Finding Type,
creating a tailored policy that targets the specific risk patterns you want to address.

You can also use the AND/OR options to build more precise logic: each AND bracket defines a set
of conditions that must all be met, and multiple brackets can be combined with OR to evaluate
different sets of conditions independently.

Refer to Cortex Cloud Application Security CI/CD policy Condition attributes for more information
about condition attributes.

c. Select Next.

5. On the Scope step of the wizard.

a. Define the scope of the assets to be evaluated by the policy by Asset Types or Asset Groups:
For Asset Types: Select Add Filters → select an asset type → select a value from the Value
field.

The following asset types and values are supported.

Category. Values: Application, CI/CD Instance, CI/CD Pipeline, VCS Collaborator, VCS
Organization

NOTE:

When you select a category (such as Application), a list of available asset values for
that type is displayed. The policy will automatically apply to all assets in the
displayed list unless you apply additional filters using specific asset attributes (such
as the Business Application Names filter).

Business Application Names: Enter names in the text field

Application Business Criticality. Values: Critical, High, Medium, Low

Application Business Owner: Enter names in the text field

CI/CD Instance Name: Enter instance names in the text field

CI/CD Instance ID: Enter Instance IDs in the text field

CI/CD Pipeline Name: Enter pipeline names in the text field

CI/CD Pipeline ID: Enter pipeline IDs in the text field

VCS Collaborator Name: Enter user names in the text field

VCS Collaborator Email: Enter user emails in the text field

VCS Collaborator MFA Enabled: Values: Select All, Yes, No

VCS Collaborator Last Observed

VCS Organization Name: Enter VCS organization names in the text field

Repository Name: Enter repository names in the text field

Is Public Repository: Values: Select All, Yes, No

Provider: Values: AWS Code Build, AWS Code Commit, Azure Repos, Bitbucket,
Bitbucket Data Center, Circle CI, Cortex CLI, GiHub, GitHub Actions, GitLab, GitLab
Self-Managed, HCP Terraform Tasks, HCP Terraform Enterprise Run Tasks, Jenkins

NOTE:

SBAC scope-based limitations do not apply to Asset Types

For Asset Groups:

Select the asset groups on which this policy and its chosen detection rules will be
evaluated. You can only select asset groups that are assigned to you as part of your
scope

The policy is evaluated only on the relevant assets within the selected group, based
on the asset types defined in the category filter
 For more information about Cortex Cloud Application Security Asset Groups, refer to SBAC
Scope-based access control for Cortex Cloud Application Security

b. Click Next.

6. On the Triggers & Action step of the wizard.

a. Trigger type: Periodic Scan (required and selected by default).

Periodic scan is the only trigger that is supported for CI/CD policies.

b. Create an Issue (required and selected by default). Optionally you can select Override Severity
and choose a severity level to be assigned to the issue.

c. Click Next.

7. On the Summary step of the wizard: Review the policy settings and click Apply.

This step provides an overview of the configured policy, including its name and description, the
configured scope, and a table of conditions, triggers, and actions. It also displays the user who created
the policy and the creation date.

You can view the custom policy that you created in the general policies table on the AppSec Policies
page.

[Link] | Cortex Cloud Application Security CI/CD policy Condition attributes

Abstract

Learn about Application Security CI/CD policy Condition filters and attributes.

CI/CD policy Condition attributes allow you to narrow and focus your policy on specific configurations and
risks within your pipelines, workflows and VCS systems.

The following attributes are supported:

 Severity. Values: Select All, Critical, High, Medium, Low

Backlog Status. Values: Select All, Backlog, New

For more information about Backlog Status, refer to Backlog baseline

Respect Developer Suppression. Values: Select All, Yes, No

For more information on developer suppressions, see ??? below

Category. The top-level domain for organizing security findings. Values: Configuration, Vulnerability,
Malware, Identity, Data, Code, Posture, Brand Protection

Provider: The CI/CD platform where the policy will look for misconfigurations. Values: Select All, GitLab
CI, Azure Pipelines, GitHub Actions, Circle CI, Jenkins

AppSec Rule: A multi-selection list of available detection rules. Use the search field to find and select
the relevant rules

AppSec Rule Label: A multi-selection list of available rule labels

Subcategory: Subcategories follow the OWASP Top 10 CI/CD Security Risks and similar standards.
They define the specific technical security domain or attack vector being addressed, acting as granular
filters that allow you to fine-tune the policy to target highly specific risks within your pipelines and VCS
assets.

Subcategory Values: Third Party Services, Artifact Integrity Validation, Credential Hygiene, Data
Protection, Dependency Chains, Identity & Access Management, Input Validation, Flow Control
Mechanisms, Pipeline Based Access Control, Poisoned Pipeline Execution, System Configuration

11.4 | Manage Cortex Cloud Application Security policies

Manage your custom Cortex Cloud Application Security policies to maintain an effective application security
posture and adapt your security rules to evolving threats and requirements.

To manage policies, right-click on a policy in the table or select a policy and then select the menu in the side
panel. The following actions are available:
 Edit: Redirects to the policy wizard, allowing you to modify the policy

NOTE:

You cannot edit out-of-the-box (OOTB) policies.

Duplicate: Clone default policies as templates for creating custom policies. When this option is selected,
the policy wizard is displayed with the original policy configurations, allowing you to modify them as
required

NOTE:

The duplicated policy will include the word "clone" in its name and must be renamed.

Disable: Enable or deactivate the policy without deleting it. Future scans will not trigger the policy, but
existing issues detected by the policy will persist. Bulk actions are supported, allowing you to disable
multiple policies simultaneously

Enable: Activates the policy configuration, making it active for all subsequent scans and enforcement
gates.

Delete policy (Custom policies only): Permanently remove the policy from your environment. Issues
detected by the policy will persist. Bulk deletions are supported

12 | Application Security Rules

Abstract

AppSec rules detect security threats using predefined criteria based on standard compliance frameworks and
best practices. Custom rules are supported.

Cortex Cloud Application Security rules are designed to detect security threats within your application security
environment, which includes the various components, configurations, and interactions within your application
that can potentially introduce vulnerabilities or pose risks to its security. Cortex Cloud Application Security
rules identify and flag issues based on predefined criteria, ensuring that potential threats are proactively
detected and addressed to enhance the overall security posture of your application.

Cortex Cloud Application Security rules cover a wide range of security best practices, inspired by compliance
frameworks such as PCI, GDPR, ISO 27001:2013, and NIST, as well as additional best practices beyond
regulatory requirements.

In addition to default rules, you can create custom rules to tailor to your specific security requirements.

NOTE:

Out-of-the-box rules cannot be modified directly. However, you can create a custom rule by cloning the
existing one. This allows you to make changes to the original rule according to your requirements. Refer to
Manage Cortex Cloud Application Security custom rules for more information.

12.1 | Roles and permissions

These user roles and permissions are required for AppSec rules:
 Users with Rules Read permission can view detection rules

Users with rules Rules View/Edit permissions can create and modify detection rules

Both AppSec Admins and DevSecOps roles only have view permissions

12.2 | Rules inventory

To access Cortex Cloud Application Security rules, under Modules select Application Security → AppSec
Rules (under Policy Management).

The Cortex Cloud Application Security rules inventory includes both out-of-the-box and custom rules. The
following list describes rules fields/properties displayed in the inventory table. By default, rules are displayed
according to severity and then alphabetically. Details are provided for properties that require explanation. You
can enable or disable rules by checking the box next to the rule name in the table.

Attribute/Property Description

Rule Name The rule name

Rule Description A description of the rule

Severity The severity level assigned to findings identified by

the rule

Scanner The type of Application Security scanner

configured to detect violations of this rule

Policies Count The amount of policies that included the rule in its
configuration

Last modified The date and time when the rule was most recently
updated

Labels Labels assigned to the rule

Framework/Language The framework or language that the detection rule

applies to (for example, GitHub, Terraform,
JavaScript)
 Attribute/Property Description

Issues Count The amount of issues generated from findings

detected by the rule. Select the value to navigate
directly to the dedicated Issues page for the
corresponding scan type, Filtered by the issues
detected by the rule

Mapped Cloud Security Rule The corresponding Cloud Security Posture

Management (CSPM) rule ID that is linked to this
Application Security rule. This mapping enables
unified policy enforcement and ensures consistent
security governance from code to cloud

How to search for Cortex Cloud Application Security rules

Use filters to find specific rules or categories.

Example 4. Examples

To filter rules relating to Secrets, select filter icon → Scanner (from the Select field) → Secrets (from the
Value field).

To view custom rules only, select Mode from the Select field, not equals as the operator, and Out-of -the-
box as the value

Sort rules according to their attributes, such as issue severity, to prioritize remediation efforts

12.3 | Create custom Cortex Cloud Application Security rules

Create custom Cortex Cloud Application Security rules to tailor your security measures to address specific
and unique threats to your organization that are not covered by default rules. Custom rules run across branch
periodic, PR, and CI scans.

Use the custom rule builder to create rules from scratch or clone and customize existing rules, enabling you to
tailor them to meet your specific requirements effectively.

You can create custom rules for:

Secrets scans

IaC scans. Supported frameworks include Terraform, TFPlan (with automatic application of Terraform
custom rules), CloudFormation, Kubernetes, Bicep, Helm, Kustomize, Helm and ARM. These scans also
apply to serverless deployments

To create custom rules:

1. Under Modules select Application Security → AppSec Rules (under Policy Management) → Add Rule.

2. On the New Rule dialog box:

a. Provide these details:

Name: The name of the rule

Impact: Describes the potential impact of a detected violation. This description is displayed
in the Issues page as well as PR Comments

Severity(required): Determines the priority level assigned to findings identified by the rule

Scanner (required): The type of scanner to be used to detect issues based on the rule

Category (required): Refines the scope of the rule. Values include General, IAM, Monitoring,
Networking, Public, Storage, Compute, Kubernetes, Logging, and AI/Machine Learning

Subcategory (required): Further refines the scope of the rule by specifying particular
attributes within the selected category

After selecting the category and sub-category, a description of the rule finding that will be
based on these selections is displayed.

Example 5. Example

If IAM is the category, and Overly Permissive is the sub-category, the finding type
description is: "Based on the categorization, finding type will be "Overly permissive IAM
policies configuration found in infrastructure as code"".

Framework: The framework or language that the rule is designed to apply to, such as
Terraform, CloudFormation and ARM

Labels: Assign tags to rules to help categorize, filter, and organize them for easier
identification and management

Mapped Runtime Rule: Select a runtime rule from the menu to map to your custom build
time rule. This enhances your code-to-cloud visibility, allowing you to prioritize findings
which are detected in both build and deployed environments

b. Click Next.

3. On the Rule Configuration screen.

a. Provide your rule definition as YAML.

NOTE:

See Configure YAML file properties below for more details.

b. Validate the code: Click Validate Code.

c. Provide suggested remediation in AsciiDoc format.

d. Click Done.
 The rule is displayed in the rules inventory table.
NOTE:

Scanning/testing behavior is not supported.

12.4 | Manage Cortex Cloud Application Security custom rules

You can manage Cortex Cloud Application Security detection rules to customize and optimize your security
configurations according to your specific needs and preferences: On the AppSec Rules inventory, right-click
on a rule or click to open the side panel → select an option:

Edit: Opens the Edit Rule wizard, allowing you to manage existing rules

Duplication: Opens the selected rule in a New Rule dialog box, allowing you to save a copy of the rule.
This allows you to customize default rules according to your requirements

12.5 | Configure YAML file properties

You can leverage YAML templates to create complex rules tailored to specific compliance or security
requirements. Cortex Cloud Application Security rules support attribute-based and connection-state rules.

Rule attributes properties (YAML)

The following YAML attributes are used to define the properties of the rules.

provider: Specifies the cloud provider or source for the resources

definition: Contains the logic and conditions for the rule, including attributes, operators, and resource
connections

resource_type: Defines the type of the specific cloud resource

cond_type: Represents the condition type for applying the rule. Options: attributes, connection, filter,
resource

attribute: Refers to the specific attribute or property of the cloud resource being evaluated

value: Represents the value that the attribute of the cloud resource should meet for the rule condition

Attribute-based rules

Attributes define resource property configurations. The YAML syntax for attribute configurations aligns with the
framework targeted by the rule, such as Terraform, to define the desired resource state. Cortex Cloud
Application Security IaC rules identify and flag any resource that deviates from this defined state as a violation.

Each resource must include one of the following conditions:

 Contain the specified attribute values. For example, if a rule states that the region attribute must be
us-west-2, then a resource will only pass this part of the rule if it includes the region attribute, and
the value of that attribute is us-west-2

Match the attribute's presence. For example, if a rule states "the encryptionEnabled attribute must
be present," then a resource will only pass if it includes the encryptionEnabled attribute, regardless
of its value

Match the attribute's absence: For example, if a rule says "the publicAccessAllowed attribute must
be absent," then a resource will only pass if it does not include the publicAccessAllowed attribute

Example 6. EXAMPLE

In this example, the attribute check flags any aws_redshift_cluster resource where the
automated_snapshot_retention_period is not 0.

definition:
cond_type: "attribute"
resource_types:
- "aws_redshift_cluster"
attribute: "automated_snapshot_retention_period"
operator: "not_equals"
value: "0"

Supported Operators: Attribute operators apply differently based on the scan type:

For IaC scans: All attribute operators are supported

For Secrets scans: You must implicitly use the regex operator. Even if regex is not explicitly defined,
pattern matching is applied automatically. For example, in the following secret rule, regex is implicitly
applied:

cond_type: "secrets"
value:
- "[A-Za-z0-9]{8,20}"
- "my-super-secret-password-regex"

The table below explains how to use attributes with matching keys and values.

Operators Values

Equals equals

Not Equals not_equals

Regex Match regex_match

Not Regex Match not_regex_match

 Operators Values

Exists exists

Not Exists not_exists

One Exists one_exists

Any any

Contains contains

Not Contains not_contains

Within within

Starts With starting_with

Not Starts With not_starting_with

Ends With ending_with

Not Ends With not_ending_with

Greater Than greater_than

Greater Than Or Equal greater_than_or_equal

Less Than less_than

Less Than Or Equal less_than_or_equal

 Operators Values

Subset subset

Not Subset not_subset

Intersects intersects

Not Intersects not_intersects

Limitation of nesting in NOT blocks

Nesting connection condition types within a NOT block is not currently supported. The following example
displays an unsupported 'NOT' block for connection condition types.

Example 7.
definition:
not:
cond_type: "connection"
resource_types:
- "aws_elb"
connected_resource_types:
- "aws_security_group"
operator: "exists"

Using JSONPath with operators

Operators within this system support advanced attribute targeting through JSONPath expressions. To apply an
operator to a JSONPath result, prefix the operator with jsonpath_. This allows for flexible and precise data
extraction and comparison. For example: jsonpath_length_equals or jsonpath_length_exists .

Connection-based rules

Connection state in a rule defines whether resources of different types are connected or disconnected. This
helps enforce security controls and architectural constraints by specifying allowed or prohibited relationships
between resources.

Example 8. EXAMPLE

In this example, aws_lb and aws_elb must be connected to aws_security_group or

aws_default_security_group to be compliant.

definition:
cond_type: "connection"
resource_types:
- "aws_elb"
- "aws_lb"
connected_resource_types:
 - "aws_security_group"
- "aws_default_security_group"
operator: "exists"

The table below explains how to use Connection State types with matching keys and values.

Key Type Value

cond_type string A connection must exist between

the specified resources

resource_type collection of strings Use either all or [included

resource type from list]

connected_resource_types collection of strings Use either all or [included

resource type from list]

operator string exists/not exists

The table below explains how to use Connection State operators:

Connection State Operators Value

Exists exists

Not Exists not_exists

Logical operators (AND/OR)

A rule can include layers of defined attributes, connection state, or both. To define the relationship between
them, use AND/OR logical operators. You can customize the attributes, connection state, or both across
multiple layers.

Example 9.

In this example, the attribute property is evaluated using OR logic to enforce compliance checks for ensuring
all AWS databases have a backup policy.

Read more...
metadata:
name: "Ensure all AWS databases have Backup Policy"
 guidelines: "In case of non-compliant resource - add a backup policy configuration for the resource"
category: "storage"
severity: "medium"
scope:
provider: "aws"
definition:
or:
- cond_type: "attribute"
resource_types:
- "aws_rds_cluster"
- "aws_db_instance"
attribute: "backup_retention_period"
operator: "not_exists"
- cond_type: "attribute"
resource_types:
- "aws_rds_cluster"
- "aws_db_instance"
attribute: "backup_retention_period"
operator: "not_equals"
value: "0"
- cond_type: "attribute"
resource_types:
- "aws_redshift_cluster"
attribute: "automated_snapshot_retention_period"
operator: "not_equals"
value: "0"
- cond_type: "attribute"
resource_types:
- "aws_dynamodb_table"
attribute: "point_in_time_recovery"
operator: "not_equals"
value: "false"
- cond_type: "attribute"
resource_types:
- "aws_dynamodb_table"
attribute: "point_in_time_recovery"
operator: "exists"

Example 10.

In this example, both AND/OR logical operators are utilized to evaluate both attribute and connection state
properties in order to enforce compliance checks for ensuring that all Application Load Balancers (ALBs) are
only connected to HTTPS listeners.

Read more...
metadata:
name: "Ensure all ALBs are connected only to HTTPS listeners"
guidelines: "In case of non-compliant resource - change the definition of the listener/listener_rul protocol
value into HTTPS"
category: "networking"
severity: "high"
scope:
provider: "aws"
definition:
and:
- cond_type: "filter"
value:
- "aws_lb"
attribute: "resource_type"
operator: "within"
- cond_type: "attribute"
resource_types:
- "aws_lb"
attribute: "load_balancer_type"
operator: "equals"
value: "application"
- or:
- cond_type: "connection"
resource_types:
- "aws_lb"
connected_resource_types:
- "aws_lb_listener"
operator: "not_exists"
- and:
- cond_type: "connection"
resource_types:
- "aws_lb"
connected_resource_types:
- "aws_lb_listener"
operator: "exists"
- cond_type: "attribute"
resource_types:
- "aws_lb_listener"
attribute: "certificate_arn"
operator: "exists"
- cond_type: "attribute"
resource_types:
- "aws_lb_listener"
attribute: "ssl_policy"
operator: "exists"
- cond_type: "attribute"
resource_types:
- "aws_lb_listener"
attribute: "protocol"
operator: "equals"
value: "HTTPS"
- or:
- cond_type: "attribute"
resource_types:
- "aws_lb_listener"
attribute: "default_action.[Link]"
operator: "equals"
value: "HTTPS"
- cond_type: "attribute"
resource_types:
- "aws_lb_listener"
attribute: "default_action.[Link]"
operator: "not_exists"
- or:
- cond_type: "connection"
resource_types:
- "aws_lb_listener_rule"
connected_resource_types:
- "aws_lb_listener"
operator: "not_exists"
- and:
- cond_type: "connection"
resource_types:
- "aws_lb_listener_rule"
connected_resource_types:
- "aws_lb_listener"
operator: "exists"
- or:
- cond_type: "attribute"
resource_types:
- "aws_lb_listener_rule"
attribute: "default_action.[Link]"
operator: "equals"
value: "HTTPS"
- cond_type: "attribute"
resource_types:
- "aws_lb_listener_rule"
attribute: "default_action.[Link]"
operator: "not_exists"
Example 11.

In this example, OR logic is applied to custom secrets defined as part of a policy aiming to enforce security
measures by restricting the addition of certain types of secrets.

Read more...
metadata:
name: "My Secret"
guidelines: "Don't add secrets"
category: "secrets"
severity: "high"
definition:
cond_type: "secrets"
value:
- "[A-Za-z0-9]{8,}"
- "my-super-secret-password-regex"

13 | Application Security CLI

The Application Security CLI, part of the Cortex CLI, allows developers and security teams to integrate
security checks directly into their application development workflows.

NOTE:

For detailed information about the Cortex Cloud CLI, refer to Cortex CLI.

The Code Security CLI supports the following scan types:

Secrets: Identifies exposed sensitive secrets within your codebase

Infrastructure-as-Code (IaC): Analyzes infrastructure configuration files to detect potential security

misconfigurations

Software Composition Analysis (SCA): Performs vulnerability detection in third-party dependencies,

assesses their license compliance and their package operational risk

In addition, the Code Security CLI serves as the integration mechanism for security scanning within supported
CI tools such as Jenkins, GitHub Actions, and others. This is achieved by adding a code snippet containing
the CLI command into the configuration files of your CI tool when integrating the CI tool with Cortex Cloud. It
acts as a wrapper, enabling security scanning within your pipelines, and direct upload of results to the
platform.

The CLI supports the following outputs:

 json

spdx

cli

junitxml

sarif

cyclonedx

cyclonedx_json

Code Security CLI scan behavior and output

Scans generate assets (see Code Security assets, issues, and findings

If one scanner (such as Secrets) fails, the other scanners will continue to run and produce results

Scan failures trigger an error message indicating the scanner that failed

The Code Security CLI provides these output modes for flexible management and viewing of scan
results:

Upload to platform: --upload-mode = true (default). Uploads scan results directly to the
platform for centralized analysis and management

Upload findings only. --upload-mode = false (default). Upload findings, but without including
the actual source code content. This prevents raw source code from leaving your local
environment or being stored on the platform

CLI output only: upload = false (default). View scan results directly in your command-line
interface without being uploaded to the platform

For more information about the output flags, refer to Cortex CLI Cortex Cloud Application Security
command line reference.

Authentication

To authenticate the Code Security CLI, choose one of the following methods:

Using command-line flags: Provide authentication details directly with your commands

The following flags are required to authenticate the Code Security CLI:

--api-base-url: [$CORTEX_API_BASE_URL]

--api-key: [$CORTEX_API_KEY]

--auth-id. [$CORTEX_AUTH_ID]

For more information about these flags, refer to Cortex CLI common command line reference guide.

Using a [Link] file: Place your authentication details in a [Link] file

Requirements

PREREQUISITE:

For the Cortex CLI binary:

Ensure you have [Link] v22 installed on your host machine before running any scans with
the Cortex CLI. This is crucial to prevent runtime errors, as the CLI depends on [Link] for
executing JavaScript analysis

NOTE:

To check your version of [Link], run node -v

To download [Link], refer to the official [Link] site

For Linux OS systems, ensure that GLIBC (GNU C library) version 2.35 or greater is installed

NOTE:

This requirement does not apply when using the CLI as a container image.

Permissions: Ensure you have the required user permissions. Refer to Overview for more information

Onboard and install the Cortex CLI. Refer to Connect Cortex CLI for more information

Configure proxy for the Code Security CLI

When operating the Code Security CLI within environments requiring internet access via a proxy server, you
can configure the tool to route its traffic through your proxy using standard environment variables. For proxies
that perform TLS inspection, you must also specify a CA certificate

Environment variables: Set HTTP_PROXY and HTTPS_PROXY (or http_proxy and https_proxy) to
your proxy address

CA Certificate: The --ca-certificate flag (which can also be configured via the
$CORTEX_CODE_CA_CERTIFICATE environment variable) must be used to provide the custom CA
certificate for proxies that perform TLS inspection

13.1 | Connect Cortex CLI

Connect Cortex CLI to scan supported Cortex Cloud modules and gain insights into your security posture,
enabling you to identify, analyze and address potential risks.

PREREQUISITE:
System requirements:

macOS (Intel Core i7, such as Sequoia): To ensure all functionalities work correctly, you must
install the vectorscan dependency via Homebrew, using this command: brew install
vectorscan

RHEL 8.10 and Red Hat UBI9. The following prerequisites must be met:

Install patchelf

Install zstd

Ubuntu 20 requires the prefetch utility

Ubuntu (for linux-amd64) also requires the libhyperscan5 library. To install, run sudo apt
install libhyperscan5

Linux for AppSec Module: Support is provided for systems meeting the following
specifications:

RHEL 10: Kernel: 6.12, glibc: 2.39

Debian 12: Kernel: 6.1.27, glibc: 2.36

Ubuntu:

Version 18.04 - Kernel: 4.15, glibc: 2.27

Version 20.04 - Kernel: 5.4, glibc: 2.31

Version 22.04 - Kernel: 5.15, Glibc: 2.35

Version 24.04 - Kernel: 6.8, Glibc: 2.39

Windows: AMD 64 and ARM 64

For cURL-based downloads:

curl

jq

On Ubuntu/Debian-based Linux distributions: sudo apt-get install jq

On RedHat/CentOS/Fedora: sudo yum install jq

macOS (using Homebrew): brew install jq

Windows:

Download the executable from jq GitHub releases

If Chocolatey is installed: choco install jq

Permissions: Grant the user installing the CLI required permissions. For more information refer to
Cortex CLI

Best Practice (required for SCA vulnerability suppression):

 Run the CLI within your current working directory (<current_directory_path>). It is recommended
to use the absolute file path for your current working directory

Ensure that the --repo-id parameter includes

the <repo_owner_name>/<repo_name> structure, with the <repo_name> matching the
exact name of the directory

Example 12. Example

The present working directory is Users/test/<repo_name>. Therefore, the --repo-

id parameter must be --repo-id <repo_owner_name>/<repo_name>, ensuring
that <repo_name> precisely matches the directory name within the structure.

For terminal actions performed by Cortex Cloud IDE extensions on Windows, Command Prompt
(CMD) is the supported environment. PowerShell is not supported for these actions

1. Navigate to Settings → Data Sources (Under Data Collections) → + Data Source → Show More →
CI/CD.

TIP:

You can also locate your CI tool by typing its name (such as Jenkins) into the search bar on the Add
Data Source page after selecting + Data Sources.

2. Hover over Cortex CLI and click Connect.

TIP:

You can enter CLI in the search bar to locate the Cortex CLI tool.

3. In the Configure step of the integration wizard.

a. Select your operating system from the menu.

b. Download the CLI binary: copy (or download) the command provided in the wizard and paste into
your terminal.

c. Click Next.

The Authenticate step of the wizard is displayed.

4. On The Authenticate step of the wizard.

a. Generate an API:

i. Select Generate API key.

IMPORTANT: This option is required for CWP image scans

This option creates a CLI role for the API key with CLI View/Edit options. It is
recommended as it grants the API key permissions to not only access data, but also
to upload or send data back

If you do not select this option, the generated API key creates a CLI Read Only role
with CLI View permissions only

Warning: Using With upload results permissions may incur additional costs as per
your license agreement
 ii. Copy the the generated API Key ID and API key that are displayed in their respective
fields.

iii. Copy and save the the generated API key from the Retrieve your API key field.

A code command is generated and displayed.

iv. Verify that the generated API key is displayed under the API Keys inventory.
NOTE:

Using an existing API Key (or verifying existing API Key permissions): If you are using an
existing API key, verify it has CLI permissions. CLI View/Edit permissions correspond to
selecting With upload results permissions, while CLI Read Only or View permissions
corresponds to not selecting the With upload results permissions.

b. Download and save the CLI tool to your system:

i. Copy or download the provided code.

NOTE:

On macOS arm 64 architecture you must unpack the downloaded file to retrieve the
executable.

ii. Replace ${API_KEY} in the code with your API key.

iii. Retrieve and paste the Cortex Cloud public API URL in the code: Navigate to Settings →
API Keys (under Configurations) → click Copy API URL .

c. Run the command in your terminal.

d. Click Done.

5. Make the cortexcli file executable: run chmod +x cortexcli.

NOTE:

To add an additional CLI instance, navigate to Settings → Data Sources → select the menu for your
connected CLI instance → + New Instance, and repeat the onboarding steps.

Download and run the Cortex CLI

1. Download the CLI: Run curl -k -u $CORTEX_API_ID::$CORTEX_API_KEY --output

./cortexcli $CORTEX_FQDN/api/v2/remote-li/{version}/{platform}/artifacts

2. Execute the CLI: Run chmod +x cortexcli.

3. Verify installation: Run cortexcli -v.

The CLI version is displayed.

Authentication

You can authenticate the Cortex CLI using one of two methods: command-line flags or an environment
configuration file.
 Using command-line flags: Provide your API credentials and base URL directly in the command using
the following flags

--api-base-url: [$CORTEX_API_BASE_URL]

--api-key: [$CORTEX_API_KEY]

--api-key-id [$CORTEX_KEY_ID]

For more information about these flags, refer to Cortex CLI common command line reference guide.

Using an environment configuration file: Instead of using flags, you can create an environment
configuration file named [Link]. Save this file in your working directory and add your credentials
as variables:

CORTEX_API_KEY: <api key id>

CORTEX_API_KEY: <secret>

CORTEX_API_BASE_URL: <tenant URL>, for example [Link]

[Link]/

Cortex CLI usage

To execute a Cortex CLI scan, run cortexcli [global flags] [module name] scan [module
flags].

Command breakdown
 Global flags:

--api-base-url <value>

--api-key <value>

--api-key-id <value>

cortexcli acts as the global option, establishing the environment for subsequent Cortex CLI
commands

Module name: Select the module (environment) to be scanned:

api for API Security. For more information about API Security scans, refer to Cortex CLI for API
Security

image for CWP. For more information about CWP scans, refer to Cortex CLI for Cloud Workload
Protection

code scan for Cortex Cloud Application Security. For more informations about Cortex Cloud
Application Security refer to Cortex CLI for Cortex Cloud Application Security

Module flags: The flags available for the selected command:

For flags common to all environments, refer to Cortex CLI common command line reference guide

For flags specific to CWP refer to Cloud Workload Protection command line reference

For flags specific to API Security, refer to Cortex CLI API Security command line reference guide

For flags specific to Cortex Cloud Application Security, refer to Cortex CLI Cortex Cloud
Application Security command line reference

NOTE:

For more information about CLI usage for CWP, refer to Cortex CLI for Cloud Workload Protection

For more information about CLI usage for API Security, refer to Cortex CLI for API Security

For more information about CLI usage for Cortex Cloud Application Security, refer to Cortex CLI usage
for Cortex Cloud Application Security

13.2 | Cortex CLI usage for Cortex Cloud Application Security

To scan Cortex Cloud Application Security, run:

cortexcli –-api-base-url <API URL> --api-key <API key from the "Authenticate" step in the CLI connector screen>
--api-key-id <API Key ID> code scan --directory {{DIRECTORY}} --branch main --repo-id organization/repo-name –
output json --output-file-path ./[Link]

Command line reference

The command structure includes global flags which are used for authentication, and then specifies the
module name and command specific to Cortex Cloud Application Security which are followed by dedicated
flags unique to this module as well as flags common to all modules.
 Global flags: These flags are part of the initial cortexcli command and are necessary to authenticate
and connect to Cortex Cloud

--api-base-url: (Required = true). The public facing API URL. Refer to Connect Cortex CLI for
more information

--api-key: (Required = true). The Cortex Cloud API key generated when onboarding the CLI as
a data source. Refer to Connect Cortex CLI for more information

--api-key-id: (Required = true). The Cortex Cloud API key ID generated when onboarding the
CLI as a data source

For a comprehensive list of Cortex Cloud Application Security global flags, refer to Cortex CLI Cortex
Cloud Application Security command line reference

Cortex Cloud Application Security specifics: Following the global flags, the command specifies the
module and the commands required for initiating a scan using the Cortex Cloud Application Security
module:

code scan: Required - true. This command instructs the CLI to perform an Cortex Cloud
Application Security scan.

For the optional flags, refer to the dedicated Cortex Cloud Application Security command line
reference

CLI Usage Examples

Send output to a file: Direct the command's output to a specified file instead of displaying it in the
console

./cortexcli --api-base-url <BASE_URL> --api-key <API_KEY> --api-key-id <API_KEY_ID> code scan --branch
<branch name> --repo-id <repo name> --directory <path> --output json --output-file-path <path>

Perform a scan without upload: Run a scan for local analysis or testing without uploading the results to
Cortex Cloud. This command runs a code scan and saves all standard output (human-readable format)
to scan_results.txt

./cortexcli --api-base-url <BASE_URL> --api-key <API_KEY> --api-key-id <API_KEY_ID> code scan --upload-
mode no-upload --branch <branch name> --repo-id <repo name> --directory <path>

Sample outputs

The cortexcli provides different options for how scan results are presented.

Standard output (stdout): When no specific output format flags (such as --output json or --output
sarif) are provided, the Cortex CLI will produce standard output directly to your terminal or console

JSON output: To obtain the output of a scan command as a JSON file, specify the flags --output
json --output-file-path ./[Link]. This command will save the detailed scan results in
JSON format to [Link] in the current directory.

Supported flags

The Cortex Cloud Application Security CLI supports both common Cortex CLI and dedicated Cortex Cloud
Application Security flags.
 For dedicated Cortex Cloud Application Security flags, refer to Cortex CLI Cortex Cloud Application
Security command line reference

For common flags, refer to Cortex CLI common command line reference guide

13.3 | Cortex CLI Cortex Cloud Application Security command line

reference
This reference guide documents the commands and flags unique to the Cortex Cloud Application Security
CLI. For CLI commands common to all supported modules refer to Cortex CLI common command line
reference guide.

IMPORTANT:

The Cortex CLI Cortex Cloud Application Security only supports single occurrences of each flag. If the same
flag is passed multiple times, only the last provided value will be used. For example, in the following
command, only TF CloudFormation will be the scanned framework.

Example 13.

./cortexcli --api-base-url <YOUR_API_URL> --api-key <YOUR_API_KEY> --auth-id <YOUR_AUTH_ID> --

framework terraform --framework "terraform cloudformation"

Command/Variable Description

--source The source of execution. Default source: CLI.

Examples: Jenkins, GitHub Actions, CLI
 Command/Variable Description

--repo-id Required for upload mode.

Identity string of the repository. Format

repo_owner/repo_name.

NOTE:

The repo-id flag must not end

with .config, .log or .ini. -config is
acceptable.

Example 14.

--repo-id [Link] will be blocked

--repo-id foo-config will pass

To retrieve the repository ID, under Inventory,

navigate to All Assets → Repositories (under Code)
→ select a repository → copy the Asset ID value
from the Properties section of the side card.

--branch Required for upload mode.

Selected branch of the persisted repository

--directory Required.

The directory path to scan. Cannot be used

together with --file

--file The file path to scan. Cannot be used together

with --directory. When using this option, the
Cortex CLI will filter runners based on the file type
provided. For example, if you specify a .tf file,
only the Terraform and secrets frameworks will be
included. You can further limit this (for example;
skip secrets) by using the --skip-
framework argument
 Command/Variable Description

--var-file Variable files to load in addition to the default files.

This feature is currently supported for both source
Terraform (.tfvars files) and Helm chart scans (for
providing custom values or variable overrides).
Refer to
[Link]
definitions-tfvars-files) for more information

--framework Filter scan to run only on specific frameworks {arm,

ansible, bicep, cloudformation, docker,
dockerfile, helm, kubernetes, kustomize,
openapi, sca, secrets, serverless,
terraform, terraform_json,
terraform_plan}

--skip-framework Filter scans to skip specific infrastructure code

frameworks. Add multiple frameworks using
spaces. For example, --skip-framework
terraform sca_package

--ca-certificate CA Certificate to use

--no-cert-verify (default: false)

--summary-position Sets the position for displaying the summary

information
 Command/Variable Description

--upload-mode Upload mode determines the method or mode

used to upload data, and includes these options:

upload : Uploads scan results to the Cortex

Cloud platform

no-upload : Disables uploads of scan

results to the platform

no-code: Uploads scan findings to the

platform, but without including the actual
source code content (code blocks in the
uploaded data

--external-modules-download-path Specifies the directory to download external

modules to. Defaults to .external_modules

--output Output format for reporting

Supported formats: cli, json, spdx, junitxml, sarif,

cyclonedx, cyclonedx_json

--output-file-path Specifies the output path for the scan result file

--deep-analysis Enables or disables deep analysis of the Terraform

plan and related files

--repo-root-for-plan-enrichment Enriches Terraform plan findings by mapping them

to their original .tf files

--skip-path Specifies a path (file or directory) that should be

skipped during the scanning process. This option
is useful for excluding specific files or directories
that are not relevant to the scanning analysis,
increasing the efficiency and accuracy of scan
results
 Command/Variable Description

--create-repo-if-missing Determines whether the system should create a

repository if it is missing. This option allows users to
automate the creation of repositories as needed
and ensure that all required repositories are
available for scanning. For example, when running
automated scans or integrating with version control
systems, enabling --create-repo-if-missing
can help maintain consistency and prevent
disruptions due to missing repositories

--compact Do not display code blocks in the output

--no-fail-on-crash Prevents the application from failing (blocking

pipelines) in the event of a scanner or backend
failure. Instead of returning a 2 exit code, it will
return a 0 exit code in such scenarios.

--var-file Variable files to load in addition to the default files,

Currently only supported for source Terraform (.tf
file) and Helm chart scans

CORTEX_APPSEC_VALIDATE_SECRETS Controls whether secret validation is performed. By

default, this feature is disabled. Set
CORTEX_APPSEC_VALIDATE_SECRETS = true
to enable it
 Command/Variable Description

--timeout Sets the maximum time the Cortex CLI will wait for
triggered local scan processes to complete.
Default value: 15 minutes.

Syntax:

To specify a duration: Use a numeric value

followed by a unit (for example --timeout
10m)

Default unit: Numeric values entered without

a unit are interpreted as seconds. For
example, 30 is equal to 30 seconds.

Supported units: Milliseconds, seconds,

minutes and hours

--help Help

13.4 | Cortex CLI common command line reference guide

This reference guide describes the common command line flags used to manage the Cortex Cloud
Application Security,Cloud Workload Protection (CWP) ) and API Security modules through the Cortex CLI,
including the structure of base commands and subcommands.

Common Cortex CLI commands and flags

The following table describes CLI commands common to all supported Cortex CLI modules.

Command Description

--api-base-url The public facing API URL. To retrieve the URL,

under Settings, select Configurations → API Keys
→ copy API URL. Required: true.
[$CORTEX_API_BASE_URL]

--api-key The API key used for authorization. Required: true.

[$CORTEX_API_KEY]
 Command Description

--api-key-id The API key ID. Required: true.

[$CORTEX_API_KEY_ID]

--soft-fail Identifies and reports errors identified during a

scan but does not trigger a failing condition.
Instead, the scan returns a successful result with
an exit code of 0. Unlike skipped or suppressed
checks, soft fail errors are still reported but do not
cause the scan to fail. Required: false.
[$CORTEX_SOFT_FAIL]

NOTE:

For soft fails, a failed check matches the defined

severity threshold. If multiple soft fail severities
are specified, the highest severity acts as the
threshold for determining a soft fail. However, a
successful scan will always return an exit code of
0, even if block-level findings (which might trigger
soft fails based on severity) are present.

--log-level Set the logging level (INFO, WARNING, ERROR)

for Stdout output

--http-proxy The HTTP proxy server URL to route traffic through

[$HTTP_PROXY]

--help Show help options

--version Retrieves the version of the Cortex CLI currently in

use

13.5 | Git Hooks

Abstract

Pre-commit and pre-receive hooks scan code changes locally and on push to detect exposed secrets.

Cortex Cloud Git hooks automatically scan your code for exposed secrets via the Cortex CLI wrapper before
code changes are pushed or committed.
The following hooks are supported:

Pre-commit hooks: Run locally before changes are committed

Pre-receive hooks: Run on the remote server before changes are pushed

13.5.1 | Cortex CLI pre-commit hooks

Abstract

Integrate Application Security secrets scanner as pre-commit hooks into your workflows to scan for errors on
your machine before local commits.

Integrate the Cortex Cloud Application Security secrets scanner as a pre-commit hook by installing the Cortex
CLI. The scanner executes the hook locally before a commit. This setup ensures that secrets checks are
enforced before any changes are committed.

When setting up pre-commit hooks, you can choose between local hooks and global hooks.

Local: Installs the hook in the .git/hooks directory of the current repository, ensuring that Cortex
Cloud Cloud secrets scans automatically run on your code before every commit

Global: Installs the hook for all Git repositories on your machine, so Cortex Cloud Cloud secrets scans
will automatically run on your code before every commit, regardless of the project

How to configure pre-commit hooks

PREREQUISITE:

These common prerequisites are required for all types of installation (both local and global) of the Cortex CLI
pre-commit hook.

Ensure you have a license for Cortex Cloud Application Security

Install the Cortex Cloud CLI binary locally. Refer to Connect Cortex CLI for information about
onboarding the CLI

Obtain Cortex Cloud API credentials (API Key ID and API Key) available from the CLI onboarding
process (see above), and your API base URL. For more information on creating API keys, refer to
[Link]

Git: You must have Git installed on your machine. For installation instructions, refer to the official Git
website

1. Create a directory:

mkdir -p ~/.cortexcli/.[Link]

NOTE:

It is recommended you configure credentials for the Cortex CLI using a configuration file.

2. Open the .[Link] file in the ~/.cortexcli/ directory and add your Cortex Cloud API
credentials and API base URL to the yaml file:

CORTEX_API_BASE_URL: <replace with the base API URL>

CORTEX_API_KEY_ID: <replace with API Key ID>

CORTEX_API_KEY: <replace with API Key>

 3. For local hooks: Install the Cortex CLI pre-commit hook package to set up a local hook for the current
Git repository:

PREREQUISITE:

For local installation: Install the pre-commit framework version 3.2.0 or greater. Refer to [Link]
[Link]/ for installation instructions.

a. For macOS, you can use Homebrew:

brew install pre-commit

For other installations run:

pip install pre-commit

b. Navigate to the root of your repository → run the following command:

cortexcli code pre-commit install --mode local

4. For Global hooks: Install the Cortex CLI pre-commit hook package to set up hooks for all Git repositories
on your machine.

cortexcli code pre-commit install --mode global

References

To set up the Cortex CLI as a pre-commit hook on supported platforms, refer to the following official Git
documentation for managing hooks:

Git Hooks: A comprehensive guide on all available Git hooks, including Pre-commit: [Link]
[Link]/book/en/v2/Customizing-Git-Git-Hooks

Atlassian Git Tutorial: A tutorial that explains the purpose and usage of both local and server-side
hooks, including pre-commit: [Link]

[Link] | Pre-commit hook usage

You can run secrets checks on your code, customize its behavior using supported flags, and suppress
detected secrets when required.

By default, Cortex CLI pre-commit hooks:

Scan staged files only: The scan performs a quick and efficient check by only analyzing the changes
you are about to commit, rather than the entire codebase

Scan for secrets only: Pre-commit hooks support secrets scans only

Do not upload results to the platform: All scan results are kept local to your machine, ensuring your data
remains private

Run a scan

To scan repositories using the Cortex CLI pre-commit command, run:

cortexcli code secrets pre-commit [options]

Command flag reference

Use the following flags with the cortexcli code pre-commit command to customize scanner behavior.

--ignore-existing-secrets: Ignores secrets that already exist from a periodic scan (default: false)
[$CORTEX_CODE_IGNORE_EXISTING_SECRETS]

--validate-secrets: Checks if the secrets are valid (default: false)

[$CORTEX_CODE_VALIDATE_SECRETS]

--skip-path: Specifies a file or directory path to skip during the scan

[$CORTEX_CODE_SKIP_PATH]

--compact: Prevents the display of code blocks in the output (default: false)
[$CORTEX_CODE_COMPACT]

--summary-position: Determines whether the summary appears on top (before the check results) or
on bottom (after the check results). (default: top) [$CORTEX_CODE_SUMMARY_POSITION]

--no-fail-on-crash: Returns exit code 0 instead of 2 in case of a failure in the integration with the
platform (default: false) [$CORTEX_CODE_NO_FAIL_ON_CRASH]

--help, -h: Displays a help message with available options

Secrets suppression

You can suppress secrets directly within your code by adding a comment. This is useful for secrets that are
intentionally included or a false positive and are not a security risk. Currently, suppression is not supported in
JSON files.

The comment format is:

cortex:skip=<SECRET_ID>:<suppression justification>

Replace <SECRET_ID> with the specific ID provided in the scan output, and provide a brief explanation for
why the secret is being suppressed. The comment syntax will depend on the file type.

Example 15. Example

Comments in a Dockerfile begin with #. Note the comment in the After suppression code-block below.

Before suppression:

ENV SEC_1="ghp_3xyKmc3W7XanE82IKHJ3Z3AfHbV"

After suppression:

# cortex:skip=APPSEC_SECRET_43: Suppress this key for testing purposes

ENV SEC_1="ghp_3xyKmc3W7XanE82IKHJ3Z3AfHbV"

13.5.2 | Cortex CLI pre-receive hooks

Abstract
Integrate the Application Security secrets scanner as a pre-receive hook into your workflows to scan for errors
before code is accepted into your repository.

Integrate the Cortex Cloud Application Security secrets scanner as pre-receive hook into your workflows
installing the Cortex CLI. The hook runs on the remote server before changes are pushed, allowing you to
enforce checks before code is accepted into version control.

Supported version control systems: Pre-receive hooks are supported for GitHub Enterprise, GitLab self-
managed, and Bitbucket Data Center. To setup pre-receive hook on these platforms refer to Setup on third-
party platforms below.

Pre-receive hook workflow setup

1. Fulfill prerequisites.

2. Configure API credentials.

3. Install the pre-receive hook.

4. Setup the pre-receive hook on third party platforms.

Setup requirements

PREREQUISITE:

Before you begin, ensure you have:

Administrator access to the VCS server and console

A valid license for Cortex Cloud Application Security

The Cortex Cloud CLI binary or Docker image installed on the server (requires GLIBC (GNU C
library) version 2.35 or greater). Refer to Connect Cortex CLI for information about
onboarding the CLI

Cortex Cloud API credentials (API Key ID and API Key) and your API base URL. For more
information on creating API keys, refer to [Link]
REST-API/Create-a-new-API-key

Git installed on your machine. For installation instructions, refer to the official Git website

Configure credentials

It is recommended to configure credentials for the Cortex Cloud Application Security Cortex CLI using a
configuration file, instead of embedding them directly in the hook script.

1. Create a directory:

mkdir -p ~/.cortexcli/.[Link]

2. Configure credentials: Open the .[Link] file in the ~/.cortexcli/ directory and add the
following configuration parameters:

CORTEX_API_BASE_URL: <API base URL>

CORTEX_API_KEY_ID: < API key ID >

CORTEX_API_KEY: < API key>

Install the Cortex CLI pre-receive hook

To install the the pre-receive hook, run:

cortexcli code pre-receive install

Setup on third-party platforms

To set up the Cortex CLI as a pre-receive hook on supported third-party platforms, refer to the official vendor
documentation:

GitHub Enterprise: About pre-receive hooks

GitLab self-managed: Git server hooks

Bitbucket Enterprise: Using repository hooks

[Link] | Pre-receive hook usage

The hook executes a script on every git push.

By default, Cortex CLI pre-receive hooks:

Only scans code changes: It analyzes the code difference included in the pushed commits, not the
entire repository

Scans for secrets only: The analysis is focused on detecting sensitive information

Does not upload results to Cortex Cloud: All scan results are kept local to your machine (on the server)

Set up the scan execution script

The shell script below defines the executable path and constructs the command, including authentication
details. It must be inserted into supported third-party platforms as a pre-receive hook to enforce scans before
commits are pushed.

#!/usr/bin/env bash

# This script is used to run Cortex CLI in a pre-receive hook.

# Use the cortex api url and key pair for your tenant.
CORTEX_API_BASE_URL='<replace with your base url>'
CORTEX_API_KEY_ID='<replace with your api key id>'
CORTEX_API_KEY='<replace with your api key>'

# Hide the update notice.

export CORTEX_HIDE_UPDATE_NOTICE=1

CORTEX_CLI="/usr/local/bin/cortexcli"
BASE_COMMAND="--api-base-url ${CORTEX_API_BASE_URL} --api-key-id ${CORTEX_API_KEY_ID} --api-key
${CORTEX_API_KEY} code pre-receive"
OPTIONAL_FLAGS=''

# Run cortex cli

${CORTEX_CLI} ${BASE_COMMAND:-''} ${OPTIONAL_FLAGS:-''}

exit_code=$?

exit $exit_code
Understanding the script variables

CORTEX_CLI: Defines the executable path, pointing to the absolute location of the cortexcli binary

BASE_COMMAND: Assembles the core command string, including authentication flags (--api-base-
url, --api-key-id, --api-key) and the primary command: code pre-receive. The use of
${...} ensures authentication variables are injected as flag values

OPTIONAL_FLAGS: An empty variable placeholder for adding optional runtime arguments

Command flag reference

Use the following flags with the pre-receive command to customize scanner behavior.

Example command structure:

$ cortexcli code pre-receive [options]

Option Description

--ignore-existing-secrets Ignores secrets that already exist in the periodic

scan (default: false)
[$CORTEX_CODE_IGNORE_EXISTING_SECRETS]

--validate-secrets Checks if the secrets are valid (default: false)

[$CORTEX_CODE_VALIDATE_SECRETS]

--skip-path Specifies a file or directory path to skip during the

scan [$CORTEX_CODE_SKIP_PATH]

--compact Prevents the display of code blocks in the output

(default: false) [$CORTEX_CODE_COMPACT]

--summary-position Determines whether the summary appears on top

(before the check results) or on bottom (after the
check results). (default: top)
[$CORTEX_CODE_SUMMARY_POSITION]

--no-fail-on-crash Returns exit code 0 instead of 2 in case of a failure

in the integration with the platform (default: false)
[$CORTEX_CODE_NO_FAIL_ON_CRASH]

--help, -h Displays a help message with available options

Breakglass: Bypassing the hook

The breakglass feature allows you to intentionally bypass the pre-receive hook security scan. This is useful in
urgent situations where a push must go through immediately, but it should be used with caution as it overrides
your security policies.

1. Configure your server to accept custom push options:

```bash
git config [Link] true
```

2. Add the -o breakglass option to your git push command:

```bash
git push -o breakglass
```

Troubleshooting and recommendations

Refer to the Cortex CLI for more information on the Cortex CLI.

Modify the script as required based on the server running the VCS

The Cortex CLI must be available on the server. This documentation does not describe the CLI
installation process

Update the Cortex CLI periodically

Instead of adding the API URL and credentials directly in the script, consider creating a
~/.cortexcli/.[Link] configuration file (owned by the git user and group) with the following
contents:

CORTEX_API_BASE_URL: <api base url>

CORTEX_API_KEY: <api key>
CORTEX_API_KEY_ID: <api key id>

14 | IDE
Abstract

Integrating the AppSec IDE security plugin to scan for misconfigurations, vulnerabilities, and secrets while
coding, with in-IDE fixes.

Integrate the Cortex Cloud security plugin into your workflow with your IDE to directly scan your infrastructure-
as-code (IaC) files for misconfigurations, detect vulnerabilities in your software composition analysis (SCA)
packages, identify exposed secrets, and uncover license violations while coding.

This process seamlessly runs in the background without disrupting your coding experience. Security findings
are flagged within your code, categorized by scan type and severity for identification and resolution within the
IDE itself. Remediation options include fixes (when available), suppression, or referring to documentation.
Supported IDEs include VS Code and all JetBrains offerings (such as IntelliJ, PyCharm and so on).

NOTE:

Not all remediation options are available for all findings or all type of scan category.
14.1 | System requirements
License: Running a supported IDE requires a license for the Cortex Cloud add-on.

Supported architectures:

macOS: arm64 and x64 (x86-64 or amd64)

Windows: x64

Supported frameworks: The IDE is compatible with all frameworks supported by Cortex Cloud Application
Security

Limitations:

Mono-repos are not supported

Special characters (such as &, parentheses) are not supported in user names within a file path). For
example, the é character in c:\Users\JohnSmithé is not supported

For terminal actions performed by Cortex Cloud IDE extensions on Windows, only Command Prompt
(CMD) is supported. PowerShell is not supported

14.2 | Visual Studio (VS) Code and VS Code compatible IDEs

Integrate the Cortex Cloud code security plugin with your Visual Studio (VS) Code or any VS Code-compatible
IDEs (such as Cursor, VSCodium, or Windsurf) to enhance security during development. The plugin scans for
security policy violations using both default and custom policies, enabling you to identify and resolve issues
before committing code, reducing the risk of pull request failures caused by undetected problems.

Choose your security level

Enhanced security with Cortex AppSec integration (recommended): For comprehensive security
analysis, connect the plugin to Cortex Cloud using your Cortex Cloud API Key and API Key ID (see
prerequisites below for more information about API keys). This option provides the full functionality of the
platform security features

Basic open-source functionality: If you prefer not to use access credentials, you can still benefit from the
plugin’s basic open-source features. These features provide a foundational level of security analysis,
helping you identify common vulnerabilities. However, you will not have access to Cortex Cloud

Supported scan categories

The plugin scans these code security categories:

 Secrets: Identifies sensitive data embedded in code, such as API keys, encryption keys, OAuth tokens,
certificates, PEM files, passwords, and pass-phrases

IaC misconfigurations in IaC templates such as Kubernetes and Terraform. For a list of supported IaC
frameworks see Supported frameworks

SCA vulnerabilities: Includes security issues in both direct and transitive open-source dependencies

Licenses: Software license noncompliance

Package Integrity: Assesses the operational risk and potential impact of each package in your
codebase

Prerequisites

PREREQUISITE:

Before you begin (These prerequisites apply to both VS Code and VS Code compatibles):

Permissions: CLI Read only permissions. Refer to Cortex CLI for more information about permissions

Environment setup

macOS and Windows: Install Python 3.9.x to 3.12.x

Install [Link] version 22 and above for SCA scans (such as vulnerabilities scans)

On the Cortex Cloud console.

Retrieve your access key and URL for authentication purposes when setting up the plugin

Generate and copy a Cortex Cloud access key to enable access to Cortex Cloud. The
access key includes a key ID and secret:

1. Navigate to Settings → Configurations → API Keys (under Integrations) → + New

Key.

2. Copy and save the key.

3. Retrieve your API Key ID from the ID column.

For more information about API keys, refer to [Link]

[Link]/r/Cloud-Onboarding-Public-APIs/Understand-Cortex-Cloud-
licenses.

For more information about API keys, refer to [Link]

[Link]/r/Cortex-XSIAM-REST-API/Cortex-XSIAM-APIs.

For more information about API keys, refer to [Link]

[Link]/r/Cortex-XDR-REST-API/Cortex-XDR-API-Overview.

NOTE:

When generating an API key, ensure you select the Standard security level.

Retrieve your Cortex Cloud API URL: Navigate to Settings → Configurations → API Keys
(under Integration) → click Copy API URL

Installation

You can install the plugin directly from your IDE extensions panel or though the Visual Studio Marketplace (for
VS Code) or the Open VSX Registry (for compatible IDEs). After completing any installation method, your IDE
will activate the extension. Restart your IDE if prompted to ensure the necessary Cortex CLI components
initialize correctly.

Install VS Code

Install through VS Code IDE

Access the Activity bar → Extensions → Cortex Cloud → Install.

Install from the Visual Studio Marketplace

1. Access the Cortex Cloud extension from the Visual Studio Marketplace (for VS Code).

2. Select Install → Open Visual Studio [Link].

You are redirected to the Cortex Cloud extension on your IDE.

3. Click Install.
Install VS Code compatibles

Install the Cortex Cloud extension from within a compatible IDE

1. Select the Extensions icon (represented by four squares) in the IDE's Activity Bar (usually on the
far left).

TIP:

You can access Extensions using the keyboard shortcuts Ctrl+Shift+X (Windows) or
Cmd+Shift+X (macOS).

2. Search the Registry: Enter Cortex Cloud in the search field at the top of the Extensions view.

The search results will pull the extension listing from the Open VSX Registry.

3. Click on the Cortex Cloud extension in the search results.

4. Select Install.

Install the Cortex Cloud extension from the Open VSX Registry

1. Download the extension package.

a. Open the Open VSX Registry

b. Select the Download link to save the .vsix extension file to your local system.

2. Install manually via the IDE Command Palette:

a. Open your compatible IDE.

b. Access the Command Palette by pressing Ctrl+Shift+P (Windows/Linux) or

Cmd+Shift+P (macOS).

c. Type or select Install from VSIX (The exact name may vary slightly, such as Extensions:
Install from VSIX...).

A file dialogue opens.

d. Navigate to the location where you saved the .vsix file in Step 1b and select it.

The IDE will process the package and activate the extension.

Configure plugin settings

The configuration process depends on whether you’re using the open-source or proprietary version. For the
proprietary version, you will need your Cortex Cloud API Key, API Key ID and and tenant URL to establish a
secure connection between your environment and Cortex Cloud. These details authenticate you to your
tenant. The open-source project does not require these settings.

NOTE:

Enforcement rules and CA certificates are not applicable to the open-source project.

1. Access the Cortex Cloud extension settings in one of these ways:

 Select Extensions → Cortex Cloud → navigate to the bottom menu bar of your VS Code editor →
select the Cortex Cloud tab

Select Extensions → Cortex Cloud → click the Settings (cogwheel) icon → Settings

2. Fill in the provided fields:

API Key ID (required): The Cortex Cloud access key ID. See Prerequisites above

API Key (required): The Cortex Cloud secret key. See Prerequisites above

Platform URL (required): Your Cortex Cloud URL. See Prerequisites above

PREREQUISITE:

You must insert your API key and API ID values into the Settings before providing the tenant
URL.

CLI Version: Leave blank to use the latest CLI version (or enter 'latest'), or specify a version

CLI Path: Specifies the path to the CLI scanner. Recommended: Leave empty to let the extension
manage the scanner installation

Disable Error Message Popups: Hide error message popups. You can view errors in the logs via
the Open Cortex Cloud Log command

Certificate: Add your Cortex Cloud CA certificate. Format: .pem file

Example 16. Example

macOS/Linux: /Users/your_username/Documents/[Link] or ~/Documents/[Link]

Windows: C:\Users\your_username\Documents\[Link]

Ignore Gitignore files: Selected by default. Files that belongs to paths included in the •
gitignore file will not be scanned when opened or saved

External Checks Directory: Provide the path to a folder containing custom security checks

Specific Frameworks: Scan specific frameworks such as ARM. You can add multiple frameworks
using spaces between the values in the command. Refer to Cortex CLI Cortex Cloud Application
Security command line reference for more information about framework flags

Environment Variables: Define specific environment variables and their values that will be
accessible to the security scanner while it performs its analysis

To add variables, select Add item → provide the variable key/value pairs → OK

To edit or delete a variable: Select the edit or delete icons next to a variable in the table

UI layout

To view the extension, select the Cortex Cloud tab in the Activity bar. The extension UI layout is as follows:
 Left pane: The Security scan panel, which includes these features:

Full Scan button: manually initiate a full scan of your project

Scan results. Features a tree structure displaying detected issues by security category (IaC
misconfigurations, Secrets, Vulnerabilities (SCA), and Licenses). Each category expands to reveal
folders containing specific issues detected during a scan

Control buttons: Provide access to Settings, Test Connectivity, Full scan play button, and
Extension Monitoring, which includes scan history and log files

Middle pane: Code editor. Review your codebase, and view a list of issues related to a file or resource
(for IaC misconfigurations), along with remediation options

Right pane: Details panel. Provides a detailed view of a selected issue, including information such as the
code difference when available, and remediation options

14.2.1 | How to use the Cortex Cloud extension in VS Code

The Cortex Cloud security extension allows you to conduct comprehensive scans, manage findings efficiently,
and remediate issues within your coding environment. You can prioritize findings and address the most critical
issues by filtering the scan results based on category and severity.

To use the extension:

1. Write your code.

The plugin provides real-time security feedback and suggestions.

2. Use the available actions and commands to resolve security issues and ensure compliance with best
practices.

UI layout

To access the plugin, select the Cortex Cloud icon in the extension panel. The UI is divided into three sections:

Left pane (Navigation panel): Displays a tree structure of issues according to security category: (IaC
misconfigurations, Secrets, Vulnerabilities (SCA), and Licenses). Expand each category to reveal folders
containing specific issues detected during a scan

Middle pane (Code editor). Allows you to review your codebase, view findings related to resources (for
IaC misconfigurations) or files, and access remediation options

Right pane (Problems Tool). Provides detailed information about a selected issue, including code
differences (when available), and remediation options

Scans

You can perform scans on an entire project or specific files:

Full scan: Click the Play button for any security category (for example, IaC and Secrets) in
the Navigation panel to scan the entire project. This action initiates scans across all categories

Selected file scan: Open or save a specific file to trigger a scan for that file only
Findings

Manage findings through either the Code editor or the Problems Tool.

Findings are grouped by security category in the Navigation panel for easy browsing

Click on a category or folder to view associated findings

Select an issue to display its details in the Code Editor and Problems Tool

Use the filter icon in the Navigation panel to refine findings by severity

Manage findings in the Code editor

To manage findings directly in your code editor, the extension highlights secrets, misconfigurations,
vulnerabilities, and license non-compliance issues with red marks next to affected lines. Hover over the marks
to view the issue's details, severity and remediation options. For multiple issues, scroll to view all detected
findings. For a more detailed view of any issue, click Console to open the Problems Tool and explore further
information about the detected finding.

Manage findings through the Problems Tool

The Problems Tool provides a detailed view of selected issues, including available remediation options. You
can access the Problems Tool by selecting an issue in the navigation bar or through the Console option in the
Code editor.

Remediation

You can mitigate issues directly through both the Code editor and the Problems Tool. Options
include Fix, Suppress, or Documentation.

NOTE:

Not all remediation options are available for all issues.

Fix issues

When selecting an issue in the Code editor or Problems Tool, a suggested fix is displayed when available.
Fixes are applied automatically upon selection. Below is a list of the types of fixes available for different issue
categories.

Secrets issues: Follow the policy guidelines

IaC misconfiguration: The fix modifies the configuration. The Problems Tool displays the code difference
to be fixed

SCA CVE vulnerabilities: You can directly fix the specific vulnerability that has been detected during the
scan by upgrading the package to the version that includes a fix

License mis-compliance: Follow the policy guidelines

Package integrity:
Suppression

Suppress an issue to temporarily hide or ignore an issue without fixing it, allowing you to concentrate on more
important issues.

NOTE:

The suppression is scoped to the file.

1. In the IDE, select an issue from the Navigation bar and click Suppress in either the Code editor or
Problems Tool.

2. Provide a justification for the suppression and click Enter to confirm.

The justification will be added as a commented annotation to your source code.

After suppressing an issue, the file will not be scanned for two minutes. This is to prevent the issue from being
re-triggered. Saving the file during the hold period will not trigger a scan.

Documentation

If automated fixes are not available, policy documentation can provide guidance on how to address the issue:
Select an issue and click Documentation. You are redirected to the relevant policy documentation which
includes suggested guidelines on how to solve the issue.

14.3 | JetBrains
Integrate the Cortex AppSec code security plugin with your JetBrains IDE instance to enhance security during
development. The plugin scans for security policy violations using both default and custom policies, allowing
you to identify and resolve issues before committing code, reducing the risk of pull request failures due to
undetected problems.

NOTE:

The Cortex AppSec code security plugin supports all JetBrains products.

Supported scan categories

The plugin scans these code security categories:

Secrets: Identifies sensitive data embedded in code, such as API keys, encryption keys, OAuth tokens,
certificates, PEM files, passwords, and pass-phrases

IaC misconfigurations in IaC templates such as Kubernetes and Terraform. For a list of supported IaC
frameworks see Supported frameworks

SCA vulnerabilities: Includes security issues in both direct and transitive open-source dependencies

Licenses: Software license mis-compliance

Package Integrity: Assesses the operational risk and potential impact of each package in your
codebase
Prerequisites

PREREQUISITE:

Permissions: CLI Read only permissions. Refer to Cortex CLI for more information about permissions

Environment setup

macOS and Windows: Install Python 3.9.x to 3.12.x

Install [Link] version 22 and above for SCA scans (such as vulnerabilities scans)

On Cortex Cloud

Generate and copy a Cortex Cloud access key to enable access to Cortex Cloud. The access
key includes a key ID and secret:

1. Navigate to Settings → Configurations → API Keys (under Integrations) → + New Key.

2. Copy and save the key.

3. Retrieve your API Key ID from the ID column.

For more information about API keys, refer to [Link]

Onboarding-Public-APIs/Understand-Cortex-Cloud-licenses.

For more information about API keys, refer to [Link]

XSIAM-REST-API/Cortex-XSIAM-APIs.

For more information about API keys, refer to [Link]

XDR-REST-API/Cortex-XDR-API-Overview.

NOTE:

When generating an API key, ensure you select the Standard security level.

Retrieve your Cortex Cloud API URL: Navigate to Settings → Configurations → API Keys → select
Copy API URL.

Installation

You can install the plugin directly through the JetBrains IDE Plugins panel or the JetBrains Marketplace.

Install through JetBrains IDE: Navigate to Settings → Plugins → select the Marketplace tab → search for
Prisma Cloud → Install → OK

Install from the JetBrains marketplace:

1. Open the marketplace.

2. Select a platform, search for the Prisma Cloud plugin, and click Get.

3. Select Download from the Versions tab and then Got it in the popup.

Configure plugin settings

1. In your IDE, select Settings → Tools → Cortex Cloud.

2. In the plugin Settings screen, fill in these fields:

 Access Key: Your Cortex Cloud API key ID

Secret Key: Your Cortex Cloud API secret key

Cortex Cloud URL: Your Cortex Cloud URL.

PREREQUISITE:

You must insert your API key and API ID values into the Settings before providing the tenant
URL.

CA-Certificate (optional): Add your CA certificate. Format: .pem file

Example 17. Example

macOS/Linux: /Users/your_username/Documents/[Link] or ~/Documents/[Link]

Windows: C:\Users\your_username\Documents\[Link]

CLI Version: Leave blank to use the latest Cortex Cloud Application Security version (or enter
'latest'), or specify a version

CLI Path: Specifies the path to the CLI executable. Recommended: Leave empty to let the
extension manage the CLI installation

Ignore gitignore files: Selected by default. Files that belongs to paths included in the •
gitignore file will not be scanned when opened or saved

External Checks Directory: Provide the path to a folder containing custom security checks

Custom Environment Variables: Environment variables passed to the scanner during scans such
as CORTEX_API_BASE_URL:

To add variables, provide the key/value pairs in the table under the Custom Environment
Variables field

To remove variables, select the (—) sign

3. Click Apply → OK.

Test connection

You can test your connection by selecting the Test Connection field under Settings.

Manage plugin configurations

Use one of these methods to access plugin configurations and modify settings:

Select the Settings icon in the Details panel

Select Settings → Tools → Cortex Cloud

UI layout

Left pane: Displays a tree structure that accurately mirrors the files and folders of the project you have
opened.

Middle pane: Displays the Code editor. When an issue is selected in the Details panel, the relevant file
opens in this editor. This allows you to examine your codebase, see the issue in its specific context
(such as an IaC misconfiguration), and find recommended remediation steps

Bottom pane: This is the Details panel. Serves as the central hub for in-depth analysis and management
of your code scan issues. It provides comprehensive information on selected issues, remediation
options scan history, and various controls such as a manual scan option.

14.3.1 | How to use the JetBrains Cortex Cloud extension

The Cortex Cloud security extension for JetBrains IDEs integrates comprehensive scanning, efficient issue
management, and remediation capabilities directly into your coding environment, without disturbing
development.

Execute scans

ou can scan your code for security issues using two primary methods: full project scans and single file scans.

Full project scans: These scans comprehensively analyze your entire project. They can be initiated in
two ways:

Automatic scan: Triggered automatically when you open a project

Manual scan: Initiated by clicking the Play button in the Details panel

Single file scan: These scans focus on a specific file. They are triggered automatically when you open or
save that file

View scan history

Select Scan History in the Details panel to view a record of past scanning activities. For each recorded scan,
you can review details such as the start time and duration of the scan, the path that was scanned, the scan
trigger (such as Manual or File Opened), the total number of issues detected, and the CLI command used to
execute the scan. Under scan history, you can also run scans locally from the terminal for support purposes
and so on.

Filters are available within the Scan History to view All Scans, Project Scans, or File Scans.

View log files

Select the Log file icon (next to the Play button in the Details panel) to view log files. These logs provide
diagnostic information and details about the execution of your scans, which can be useful for troubleshooting.

Manage issues in the Details panel

The Detail panel's main display features a series of tabs for categorizing issues. An Overview tab provides a
summary of all detected issues. Alongside it, dedicated tabs exist for specific security categories: Issues are
organized by security category (IaC, Secrets, Vulnerabilities, Licenses, and Package Integrity). The Overview
tab displays the total count of all issues, while each category-specific tab displays the total count of issues
associated with its specific type.

You can filter issues:

By severity level (L M H C) to filter issues by severity

By fix availability (Fix Available) to filter for issues with an available fix

NOTE:

After selecting Fix Available, the number of issues displayed in the issue categories (such as IaC)
reflect the number of fixable issues for that type.

The Details panel displays a hierarchical view of folders and files that contain issues, with this display
dynamically updated based on the selected issue type tab.

1. Under a scan category, browse through folders/subfolders to locate and click on a file containing
issues.

2. (Optional) Use a filter to prioritize issues.

3. Select an individual issue within the file to display its details in the right section of the Details panel.

NOTE:

The corresponding file simultaneously opens in the Code editor, highlighting the issue within its exact
code context. See below for more information.

The detailed issue view provides information including:

The name and description of the issue

The code lines (or resource for IaC misconfigurations) in which the issue has been detected

Contextual remediation options, provided specifically for each issue type to guide resolution. For
more information about remediation options, refer to Remediation options by issue category below

Manage issues in the Code editor

Select an individual issue within the Details panel to open the file containing the issue in the Code editor.

Issues are marked by a red i icon next to the code line.

Click the red i icon for basic details about an issue: name, severity, and remediation options (see below)

For IaC resources with multiple issues, hovering over the line of code marked i displays a list of issues at
the resource's starting line. Scroll to view all issues

Select Console to display the issue in the Details panel

Remediation options by issue category

You can mitigate issues directly through both the Code editor or the Details panel. Options include Fix,
Suppress, and Documentation.

NOTE:
 Not all types of remediation are available for all issue categories. For example, fixes are not available for
License issues.

Fixes

When selecting an issue in either the Code editor and Details panel, a suggested fix is displayed when
available. Fixes are automatically applied to the code upon selection. The following list displays the type of fix
available for the different categories of issues.

CVE vulnerabilities: The fix bumps the package version. You can directly fix the specific CVE
vulnerability that has been detected during the scan by upgrading the package to the version that
includes a fix

IaC misconfigurations: The fix modifies the configuration. The Details panel displays the code difference
to be fixed

Secrets issues: N/A

License mis-compliance: N/A

Package Integrity: N/A

Suppression

Suppress an issue to temporarily hide or ignore an issue without fixing it, allowing you to concentrate on more
important issues. The suppression is scoped to the file.

1. Select an issue from the Details panel → click Suppress in either the Code editor or Details panel.

2. Provide a justification for the suppression → click OK.

The justification will be added as a commented annotation to your source code.

After suppressing an issue, the file will not be scanned for two minutes. This is to prevent the issue from being
re-triggered. Saving the file during the hold period will not trigger a scan.

Documentation

If automated fixes are not available, policy documentation can provide guidance on how to address the issue:
Select an issue → click Documentation in either the Code editor or Details panel. You are redirected to the
relevant documentation which includes suggested guidelines on how to mitigate the issue.

NOTE:

Secrets and Licenses category issues are typically mitigated by following the guidance in the
Documentation.