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.

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