> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/application-security/software-supply-chain-security/risk-and-remediation/cicd-risks/understand-the-ci-cd-risks-table.md). # Understand the CI/CD Risks table The **CI/CD Risks** page combines triage widgets with a detailed issue table. Use the widgets to identify priority work. Use the table to investigate and remediate specific CI/CD risk issues. Navigate to **Application Security > Issues > CI/CD Risks**. ## Widgets Use the widgets to identify and prioritize the highest-severity issues before opening the detailed table. Selecting a widget value filters the table to matching issues. > **Important:** The CI/CD Risks finding type does not receive Urgency classification. #### The severity widget — how risk is distributed Because the CI/CD Risks finding type does not calculate Urgency, the histogram widget displays a severity breakdown. Read the proportions rather than the absolute counts. | Shape | What the shape means | What to do | | ------------------------------------------------------------- | ------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- | | A visible Critical segment | Configurations that expose privileged credentials or permit unauthorized code promotion | Commit capacity here before anything else, and confirm in Stage 3 whether the affected pipelines also accept untrusted input | | A concentration in one OWASP CI/CD category across severities | A systemic weakness in how pipelines are authored, rather than a set of independent defects | Harden the whole category in one pass | | A large Medium and Low population | Hygiene items on pipelines that hold narrow credentials | Harden on schedule, and check whether one instance is the common source | Select a segment to filter the table to that severity level. #### The SLA widget — how much of the backlog is already late The SLA widget charts open issues by SLA status. An overdue population is a commitment already broken, independent of severity. Read the SLA widget alongside the severity widget: overdue issues at a low severity are a process problem, while overdue Critical issues are an escalation. > **Note:** The severity widget and the SLA widget describe the backlog. The Insights widget builds the work queue and belongs to the next stage. #### Insights Each insight card pairs a **severity** level with another risk dimension and shows the number of issues matching both conditions. The CI/CD Risks table defines the following insight cards: | Insight | Condition | | --------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- | | **Critical issues mapped to OWASP Top 10 CI/CD security risks** | CI/CD risk issues with Critical or High severity mapped to the OWASP Top 10 CI/CD Security Risks | | **Critical issues mapped to CIS GitHub / GitLab Benchmark** | CI/CD risk issues with Critical or High severity mapped to the CIS GitHub Benchmark or the CIS GitLab Benchmark | > **Note:** A CI/CD risk affects the infrastructure that builds every application, so a single instance-level risk can invalidate the scan results of many applications at once. Read the widgets as a build-integrity assessment rather than as an application backlog. ## CI/CD Risks table The table provides a consolidated view of CI/CD risk issues. Each row represents an issue created when a scanner finding matches a unified policy. Each row links the insecure configuration to the resource where the violation occurred along with the OWASP CI/CD category, the detection rule, and the triggering policy. The table includes the following CI/CD attributes. Use the **Table Settings** menu to display the hidden columns. ### Visible columns | Column | Description | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Severity** | The severity level assigned to the risk: Critical, High, Medium, Low, Informational, or Unknown. Severity is determined by the detection rule that matched the configuration and may be overridden by a matched unified policy | | **Name** | The descriptive name of the risk, which states the insecure configuration and the resource it was detected on. The **Name** column is the primary identifier for the issue | | **File Path** | The path to the pipeline or workflow definition file that contains the insecure configuration, including the affected line range. Empty for risks detected on a VCS or instance setting rather than in a file | | **Branch** | The repository branch where the pipeline definition was detected | | **Created** | The timestamp when the issue was first detected | | **Pipeline** | The pipeline or workflow the risk was detected in | | **OWASP CI/CD Category** | The OWASP Top 10 CI/CD Security Risks category the risk is classified against | > **Note:** For the full inventory of hidden columns, refer to Reference A: Hidden columns. ### Hidden columns The following columns are hidden by default. Display any of the following columns from the **Table Settings** menu. #### Provenance and identity These columns identify where the issue came from and how to reference the issue outside the tenant. | Column | Description | | -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | | **Data Source** | The VCS provider where the pipeline or configuration is hosted: GitHub, GitLab, Bitbucket, or Azure DevOps | | **Asset ID** | The internal identifier of the CI/CD instance or pipeline asset | | **Detection Method** | The scanner that detected the risk | | **Alert Source** | The originating scanner source | | **Git User** | The Git author associated with the commit that introduced the insecure pipeline configuration | | **Finding ID** | The unique identifier of the underlying finding | | **Issue ID** | The internal issue identifier used for API operations and cross-referencing | | **Rule ID** | The CI/CD detection rule identifier that matched the configuration. CI/CD rules are out-of-the-box only; custom CI/CD rules are not supported | #### Description and remediation These columns state what the issue is and what change resolves the issue. | Column | Description | | ------------------------- | ----------------------------------------------------------------------------------------------------------------------- | | **Alert Description** | A detailed description of the risk, including the attack path the configuration enables and the recommended remediation | | **Evidence** | The evidence sentence stating what was detected and why the configuration is a risk | | **Manual Fix Suggestion** | The recommended manual remediation steps, stating the setting or workflow directive to change | #### Risk and prioritization signals These columns carry the intelligence that separates a high-blast-radius pipeline risk from a contained one. | Column | Description | | ---------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | | **OWASP CI/CD Category** | The OWASP Top 10 CI/CD Security Risks category the risk is classified against | | **Affected Pipelines Count** | The number of pipelines affected by the insecure configuration. Instance-level and organization-level risks affect many pipelines at once | | **Credential Scope** | Whether the affected pipeline holds unscoped or privileged credentials | | **Accepts Untrusted Input** | Whether the affected pipeline executes on input from outside the organization, such as a fork-originated pull request | | **Original Severity** | The severity assigned by the detection rule before any policy override | #### **Location and lineage** These columns identify where in the delivery infrastructure the risk was detected. | Column | Description | | -------------------- | ------------------------------------------------------------------------------------------ | | **Code Lines** | The line range within the pipeline definition where the insecure configuration is declared | | **Code Component** | The configuration block that triggered the detection rule | | **CI/CD Instance** | The CI/CD instance the risk was detected on | | **VCS Organization** | The VCS organization the risk was detected in | | **Domain** | The security domain classification | | **Domain Provider** | The provider domain associated with the CI/CD instance | #### Ownership and workflow These columns track who owns the issue and what state the issue is in. | Column | Description | | ---------------------- | ----------------------------------------------------------- | | **Assignee** | The user assigned to remediate the issue | | **Assignee Name** | The display name of the assigned user | | **Resolution Status** | The current resolution state: New, In Progress, or Resolved | | **Resolution Comment** | The comment provided when the resolution status was changed | | **Last Updated** | The timestamp of the most recent update to the issue | **Classification and links.** These columns categorize the issue and link out to the source system. | Column | Description | | ------------------------ | ------------------------------------------------------------------------------------------------------------------- | | **Provider Link** | A direct link to the pipeline definition or the configuration setting in the provider | | **Rule ID Link** | A link to the detection rule documentation | | **Compliance Standards** | The compliance controls the detection rule maps to, including the CIS GitHub Benchmark and the CIS GitLab Benchmark | | **Finding Category** | The category classification of the finding | | **Subcategory** | The subcategory classification of the finding | | **Tags** | User-defined or system-generated tags applied to the issue | ## Filter and sort the table Use the filter bar at the top of the **CI/CD Risks** table to narrow results by any filterable column. Apply the following strategies to scope the table to a working set. | Strategy | Filter | Use when | | ----------------------------------- | ------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------- | | Focus on impact | **Severity** set to Critical and High | You are establishing the initial working set for a hardening cycle | | Scope to a risk category | **OWASP CI/CD Category** set to a single category | You are hardening a whole class of risk rather than remediating individual findings. Category-level work is the efficient unit for pipeline hardening | | Route by owning team | **CI/CD Instance** or **VCS Organization** set to a single value | The team that owns the instance owns the fix, and you are assigning work by ownership | | Scope to a compliance program | **Compliance Standards** set to the CIS GitHub Benchmark or the CIS GitLab Benchmark | You are producing evidence against a recognized benchmark | | Separate untriaged from active work | **Resolution Status** set to New, then to In Progress | You are measuring triage backlog against hardening throughput | | Find shared-blast-radius risks | **Affected Pipelines Count** sorted descending | One instance-level configuration change resolves the risk across many pipelines at once | > **Note:** Filtering scopes the population; sorting orders it. Apply both. Grouping by **OWASP CI/CD Category** before sorting is the primary CI/CD-specific strategy, because a category concentration identifies a systemic weakness in how pipelines are authored rather than a set of independent defects. *** ## Manage issues Right-click a row in the **CI/CD Risks** table to access the following actions. | Action | Description | | ------------------------------------------ | ----------------------------------------------------------------------------- | | **Change Status** | Modify the resolution 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** | Copy the selected cell text | | **Copy entire row** | Copy the full row of data | | **Copy issue URL** | Copy the URL of the issue, to share or reference the issue | | **Show/hide rows with the severity level** | Show or hide all rows matching the severity level of the selected row | > **Note:** A remediated pipeline regresses the next time someone edits a workflow. Apply the **CI/CD Configuration Scanners** policy type to convert a one-time remediation into an enforced standard. For policy configuration, refer to Unified Application Security Policies. *** --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://cortex-docs.paloaltonetworks.com/application-security/software-supply-chain-security/risk-and-remediation/cicd-risks/understand-the-ci-cd-risks-table.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.