Investigate a scan result, prioritize the issues, and remediate

Open a scan result to determine what the scan found, establish which issues to work first, and remediate each issue directly within the scan. Start by opening your scans in order of repository business criticality.

For large repositories, issues may span multiple categories (such as secrets and vulnerabilities). Because the scan side panel does not provide a single ranked list across categories, prioritize in two stages: first across categories using the Overview tab, and then within each category using tabs.

Prioritize by Urgency (when the scan category supports Urgency), and use Severity as the tie-breaker within an Urgency tier. For detailed information about Urgency, refer to Urgency.

This deep-dive method focuses on a single scan result. To triage across your entire portfolio at scale instead, go to Application Security > Issues to view multi-repository tables with built-in risk dimensions. Refer to Code Security scanners for more information.

Procedure

1. Select a scan row in the Branch Periodic Scans inventory: Open the scans in the business criticality order recorded in Assess scan coverage and health across the portfolio, so the repositories belonging to the most critical applications are triaged first. The side panel opens, titled with the repository name and the branch name in parentheses, such as my-repo (main).
2. Review the Overview tab to establish the scope of the result and the scale of the work:

   • Organization, Repository, and Scanned Branch identify the code context of the scan
   • Scan Date records when the scan started
   • Scan Health reports execution health, and presents a Rescan control when the health value is Error or Partially (completed). Establish that the scan health reads Completed before treating the counts as a full result — see Triage a scan that failed or completed partially
   • Issues and Findings report Critical, High, Medium, and Low counts for the scan as a whole. Read the Issues counts to size the work the scan represents. The counts do not schedule the work. Scheduling follows the prioritization you apply per category at step 5, which the Overview tab does not report.
   • Issues By Type and Findings By Type report counts per scanner category, which identifies the category tabs that hold results
3. Decide which issue category to investigate first:

   Table	Ranking axis	Action in the table	Record
   Vulnerabilities, Secrets, Configurations > IaC Misconfigurations	Urgency, Severity as tie-breaker	Filter Urgency to Top Urgent. Where the filter returns no row, filter to Urgent, then to Not Urgent.	The highest Urgency tier that returns a row, and the highest severity within that tier
   Configurations > CI/CD Risks, Package Integrity > Licenses, Package Integrity > Package Operational Risk, Malicious Packages	Severity, category-specific signal as tie-breaker	Filter Severity to Critical, then to High, until a filter returns a row.	The highest severity that returns a row, and the category-specific signal named in step 5

   • Two tabs present two tables rather than one: Configurations presents IaC Misconfigurations and CI/CD Risks, and Package Integrity presents Licenses and Package Operational Risk
   • The issue categories do not correspond one-to-one with the configurable scanners. See Reference G: Scanner to issue category mapping
4. Assign each issue a single rank, then work the ranks in order. Apply the first row that matches the issue and stop — the rows are evaluated in sequence, so an issue matching several rows takes the first:

   Rank	Matches	Target SLA	Because
   1	Any Malicious Packages issue	24 hours	The package already executed. An active compromise outranks a latent weakness, and no Urgency score expresses that — this category is the one case where a category carrying no Urgency outranks one that does.
   2	Any Secrets issue with a Validation value of Valid or Privileged	24 hours	A live credential committed to the branch is exposed exactly as detected. Rank 2 is a promotion rule: it lifts a live credential above the Urgency ordering, because rotation is a containment deadline that runs whether or not the deployment context that Urgency measures exists. See Understand the Secrets table.
   3	Any issue with an Urgency of Top Urgent	24 hours	Urgency already accounts for deployment state, internet exposure, and application criticality.
   4	Any issue with an Urgency of Urgent	Current sprint	Urgency ranks the issue in your environment rather than in isolation.
   5	Any CI/CD Risks, Licenses, Package Operational Risk, or unclassified issue at Critical or High severity	Current sprint	These tables carry no Urgency tier to rank against, so severity and the category-specific signal at step 5 order them. Ranking Critical and High alongside Urgent prevents a severe issue in a table that carries no Urgency from falling behind every classified issue.
   6	Every remaining issue — Not Urgent, and Medium, Low, or Info severity in a table that carries no Urgency	Next maintenance cycle	Neither the Urgency signal nor the severity signal marks these issues for the current cycle.

   Tiebreaks: Where two issues hold the same rank, break the tie in this category sequence: Malicious Packages, then Secrets, then Vulnerabilities — where EPSS, CISA KEV, and fix availability rank issues against each other with the most confidence — then Configurations, exploitable only once the template is applied, then Package Integrity, a compliance and maintainability exposure rather than a directly exploitable condition.

   SLA: Track compliance against the target SLA in the issue table that owns the category, not in the scan side panel. The scan side panel reports no SLA status. The SLA Status values — On Track, Approaching, and Overdue — are carried on the dedicated issue tables reached from Reference D: Issue category routing.
5. Select an issue category tab and apply the ordering filter for that category. Each tab opens with the Issues table displayed, and an Issues and Findings toggle switches between the actionable records and the raw detections.
6. Select an issue in the table. The issue side card opens within the scan management context, so investigation does not require navigating to the dedicated issue page first.
7. Select the Findings tab to review the evidence underlying the issues — the name of the finding, the asset in which the finding was detected, and the repository hosting the asset. Select a finding to open the description of the finding, the asset type and asset group, the time of the last update, and the evidence for the finding.
8. Remediate the issue from the Resolution tab of the issue side card, displayed after Overview.

   The tab presents whichever remediations the platform holds for that detection, and presents both when both exist:

   • Automatic Fix appears only on IaC misconfiguration and CVE vulnerability issues produced by a periodic scan, and only when the platform generated a fix. It presents the proposed code change and an Open Fix Pull Request control that raises a pull request against the repository on your behalf. No code changes until the pull request is reviewed and approved. Once raised, the tab reports the pull request link against the issue. When a manual fix is also present, this section is titled Automatic Fix (Recommended)
   • Manual Fix appears whenever the platform holds remediation text for the detection, independently of whether an automatic fix is available. Where neither is available, the tab presents general remediation guidance for the issue category

Continue in the guide that owns the issue category for the full remediation lifecycle — see Reference D: Issue category routing.

Result: The issues of this scan are triaged in priority order, each detection is understood in the context of the scan that produced it, and remediation is started from the scan without navigating to the issue inventory.