> 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/code-security/application-security-scans-management/manage-scans-through-the-tenant-ui/ci-scans/references/reference-b-inventory-columns.md). # Reference B: Inventory columns The CI Scans inventory displays the following columns by default. Filterable columns support text-based and enum-based filtering according to the data type. ## CI inventory table | Column | Field | Description | | ------------------------------ | ---------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Repository** | `repo_name` | The name of the scanned repository, displayed with the provider icon. | | **Organization** | `organization_id` | The VCS organization or group. CLI-family integrations return an empty value. | | **Run ID** | `run_id` | The identifier of the pipeline run that produced the scan. The CI scans API does not return this field. | | **Scanned Branch** | `branch_name` | The branch the pipeline built. | | **Scan Date** | `start_date` | The timestamp when the scan started. | | **Issues Found** | `issues_found` | The severity breakdown of the issues found. | | **CI Status** | `status` | The policy evaluation result that determined the build outcome. | | **Scan Health** | `scan_health` | The execution health of the scan. | | **Business Application Names** | `business_application_names` | The business applications associated with the repository. This column is filterable but not sortable. A repository can belong to several applications. It reports application names, not criticality. | The following columns are hidden by default. Enable them from the column settings icon. | Column | Field | Description | | ------------------------------- | ----------------------------- | ------------------------------------------ | | **Provider** | `vcs_source` | The source of the scanned code. | | **Scan ID** | `scan_id` | The unique identifier of the scan. | | **Findings Types Breakdown** | `findings_types_breakdown` | The breakdown of findings by scanner type. | | **Findings Severity Breakdown** | `findings_severity_breakdown` | The severity breakdown of the findings. | | **Issues Types Breakdown** | `issues_types_breakdown` | The breakdown of issues by scanner type. | ### Scan Date filter **Scan Date** (`start_date`) records when the scan started. Where the filter is available, it limits results to scans started within the selected range. Apply the filter when an assessment must cover a defined period. Without a range, the inventory includes every retained scan result. A build that failed six months ago appears beside a build failing today. The filter reports scan results, not repositories or pipelines. A repository with no result in the range returns no row. The filter cannot distinguish it from a repository without a Cortex CLI step. Use the pipeline asset inventory to establish build-stage coverage. The Scan Date filter only bounds the assessment. ## CI scan side panel Select a scan row to open the side panel. The panel title displays the repository name with the branch name in parentheses (for example, `my-repo (feature-branch)`). **Overview tab properties:** * **Organization** — The VCS organization or group. * **Repository** — The scanned repository name. * **Scanned Branch** — The branch scanned during the CI run. * **Scan Health** — The scan health status with a status icon. * **CI Status** — The CI scan result status with a status icon. * **Issues By Type** — Breakdown of issues by scanner category. * **Findings By Type** — Breakdown of findings by scanner category. * **Scan Date** — The timestamp when the scan started. * **Issues** — Severity breakdown (Critical, High, Medium, Low) with total count. * **Findings** — Severity breakdown (Critical, High, Medium, Low) with total count. **Issue category tabs:** * **Vulnerabilities** — CVE vulnerability issues for the selected scan. * **Configurations** — IaC misconfiguration issues for the selected scan. * **Secrets** — Secrets issues for the selected scan. * **Package Integrity** — Presents two tables: **Licenses** and **Package Operational Risk**. * **Malicious Packages** — Malicious package issues for the selected scan. Each tab presents an **Issues** view and a **Findings** view, selected from the control in the upper right of the tab. ## CI scan actions No management actions (such as rescan) are available for CI scans. CI scans are triggered by CI/CD pipeline execution and cannot be retriggered from the scan management console. Re-evaluation occurs by running the pipeline again. For the complete CI scan workflow — embedding the Cortex CLI in a pipeline, verifying that the build gate fires across the portfolio, investigating a failed build, and distinguishing a policy block from a tooling failure — see CI scans. --- # 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/code-security/application-security-scans-management/manage-scans-through-the-tenant-ui/ci-scans/references/reference-b-inventory-columns.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.