> 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/branch-periodic-scans/references/reference-b-inventory-columns.md).

# Reference B: Inventory columns

## Periodic branch inventory

The Branch Periodic Scans inventory displays the following columns by default. Each column supports sorting. Filterable columns support text-based and enum-based filtering according to the data type. You can retrieve matching response fields through the [Scan Management API](/cortex-cloud-api/aspm-cicd-and-application-security/scan-management.md).

| Column                         | Field        | Description                                                                                                                        |
| ------------------------------ | ------------ | ---------------------------------------------------------------------------------------------------------------------------------- |
| **Repository**                 | `repoName`   | The name of the scanned repository, displayed with the VCS provider icon                                                           |
| **Scanned Branch**             | `branchName` | The branch analyzed during the scan                                                                                                |
| **Scan Date**                  | `scanDate`   | The timestamp of the last scan execution                                                                                           |
| **Scan Health**                | `scanHealth` | The execution health of the scan                                                                                                   |
| **Business Application Names** |              | The business applications associated with the scanned repository. Enable this column to rank scan failures by business criticality |

The following columns are hidden by default. Enable additional columns from the column settings icon in the inventory toolbar.

| Column            | Field              | Description                                            |
| ----------------- | ------------------ | ------------------------------------------------------ |
| **Organization**  | `organizationName` | The VCS organization or group that owns the repository |
| **Scan ID**       | `scanId`           | The unique identifier of the scan                      |
| **Repository ID** | `repositoryId`     | The unique identifier of the repository                |
| **Integration**   | `integrationId`    | The identifier of the VCS integration                  |
| **Scan Category** |                    | Filters results by Code, LLM, or All                   |

### Scan Date filter

The **Scan Date** column is displayed by default and is filterable by range from the inventory filter bar. The **Scan Date** filter restricts the inventory to the scan results that started within the selected range, and accepts two range types:

| Range type             | Description                                                                                                   | Use when                                                                                                                                              |
| ---------------------- | ------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Prepopulated range** | A fixed relative period counted back from the present, including last 24hours, Last 7days, and last 30 days . | Reading the current posture. At the 12-hour cadence, a seven-day range covers roughly the last fourteen scan cycles of every repository that reported |
| **Custom range**       | An explicit start date and end date.                                                                          | Bounding an assessment to a reporting period, a change window, or the interval since a specific remediation                                           |

Apply the **Scan Date** filter whenever an assessment must read a defined period rather than accumulated history. Without a range, the inventory returns every retained scan result, so a repository that failed once six months ago and a repository failing on the current cycle appear alongside each other.

The **Scan Date** filter reports scan results, not repositories. A repository that produced no scan result within the selected range returns no row, and the filter cannot distinguish that repository from a repository that is not onboarded at all. The **Scan Date** filter therefore bounds an assessment; the **Scan Date** filter never establishes scan coverage. To establish the repositories that produced no result over a period, use the unscanned repositories endpoint, for the reason given in [Assess scan coverage and health across the portfolio](/application-security/code-security/application-security-scans-management/manage-scans-through-the-tenant-ui/branch-periodic-scans/branch-periodic-scan-workflow.md#assess-scan-coverage-and-health-across-the-portfolio).

## Branch periodic scan side panel

Select a scan row to open the side panel. The panel title displays the repository name with the scanned branch in parentheses (for example, `my-repo (main)`).

**Overview tab properties:**

* **Organization** — The VCS organization or group.
* **Repository** — The scanned repository name.
* **Scanned Branch** — The branch analyzed during the scan.
* **Scan Health** — The scan health status with a status icon. A **Rescan** control appears next to the property when the health is **Error** or **Partially**.
* **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.

The periodic panel carries no **PR Status**, **CI Status**, or **Commit ID** property. A periodic scan evaluates the existing codebase on a schedule rather than gating a specific code change, so no gate verdict and no triggering commit apply.

**Issue category tabs:**

* **Vulnerabilities** — CVE vulnerability issues for the selected scan.
* **Configurations** — Presents two tables: **IaC Misconfigurations** and **CI/CD Risks**.
* **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.

## Branch periodic scan actions

**Rescan** is available on a scan with a health of **Error** or **Partially**, from the right-click menu on the inventory row or from the **Overview** tab of the side panel. A rescan appends a new row rather than replacing the existing one. Periodic scans are the only scan type with a rescan action.

For the complete branch periodic scan workflow — configuring scan coverage per repository, assessing scan health across the portfolio, routing each issue category to its resolution guide, triaging a failed or partially completed scan, and diagnosing the underlying cause through data source instance health — see Branch periodic 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/branch-periodic-scans/references/reference-b-inventory-columns.md?ask=<question>&goal=<endgoal>
```

`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.
