> 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-a-branch-periodic-scan-concepts.md).

# Reference A: Branch periodic scan concepts

Detailed concepts for interpreting branch periodic scans.

### Scan health and the gate status columns are different signals

Scan health and scan status answer different questions. Confusing them produces incorrect posture conclusions.

**Scan health** indicates scan execution health. It shows whether scanners completed, failed, or are still running. Scan health applies to branch periodic, CI, and pull request scans.

**Scan status** indicates policy evaluation results. It shows whether a scan passed, failed, or found non-blocking issues. Scan status applies only to CI and pull request scans.

> **Note:** Branch periodic scans do not have a scan status. They evaluate already committed code and cannot block merges or builds. Scan health is their only health indicator.

A **Completed** health value means every scanner completed. It does not mean the repository is secure or policies passed.

> **Note:** For every scan health value and its meaning, see [Reference C: Scan health values](/application-security/code-security/application-security-scans-management/manage-scans-through-the-tenant-ui/branch-periodic-scans/references/reference-c-scan-health-values.md).

### The inventory lists scan results, not repositories

The Branch Periodic Scans inventory displays one row per scan result. It does not display the onboarded repository population.

A repository produces no row when it is not onboarded. It also produces no row before its first scan completes.

### The Completed row count is not a coverage measure

The inventory lists scanned repositories only. Filtering **Scan Health** to **Completed** and counting the rows therefore tells you how many scans finished, not how many repositories are covered. Use [coverage](/application-security/application-security-posture-management-aspm/coverage.md) to measure the onboarded repository population. Use the scan inventory to assess repositories that reported results.

### Findings are detections; issues are policy matches

A **finding** is a raw scanner detection, such as an exposed credential or vulnerable package. An **issue** is an actionable record created when a finding matches an enabled Unified Application Security Policy.

Findings provide evidence. Issues are the records teams triage, assign, and resolve.

The overview reports both counts. A materially higher finding count may indicate intentional policy scope, a policy gap, or suppression.

Compare **Findings By Type** on the scan **Overview** in the side card with enabled Periodic Scan policies. A finding type without a matching enabled policy indicates a policy gap.

### Not every issue carries Urgency

Urgency classifies vulnerability, secret, and IaC misconfiguration issues. CI/CD risk, package integrity, and malicious package issues carry no Urgency at any point.

Where a category does carry Urgency, the classification is applied during the next periodic scan cycle rather than at the moment the issue is created. Because the cycle interval is 12 hours, a newly created issue can carry no computed Urgency for up to 12 hours.

Prioritize by Urgency once Urgency is computed. Prioritize by severity and by the business criticality of the affected repository in the interval before classification, and wherever the category carries no Urgency. Do not interpret an unclassified issue as low priority.  

For information on Urgency refer to [Urgency](/application-security/application-security-posture-management-aspm/urgency.md).


---

# 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-a-branch-periodic-scan-concepts.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.