Investigate, prioritize, and remediate secrets issues

To effectively manage secrets issues, follow this lifecycle, moving from an open backlog to a resolved and prevented issue.

Stage	Decision	Primary surface
Assess	How much capacity to commit, and to what	Urgency widget and SLA widget above the Secrets table
Prioritize	Which credential to rotate next	Insights widget above the Secrets table
Investigate	Whether the credential is usable, what the credential unlocks, and who owns the rotation	Issue side panel
Remediate	Which rotation and replacement path to apply	Resolution tab in the issue side panel
Prevent	Which enforcement point blocks recurrence	Unified Application Security Policies

Important: A secret issue differs from every other issue type in one respect that governs all five stages. Deleting the exposed value does not resolve the exposure. A credential that reached a protected branch, or that was ever pushed to a remote, must be rotated at the issuing provider. Treat this guide as a rotation workflow, not a code-cleanup workflow.

Assess

Before selecting an issue, read the shape of the backlog. Two widgets above the Secrets table answer that question, and neither is a work queue — each describes a distribution, so that you commit capacity against a measured posture rather than against the first issue you happen to open.

The Urgency widget — how risk is distributed.

The Urgency widget charts the count of open issues per Urgency level. Read the proportions rather than the absolute counts.

Shape	What the shape means	What to do
A visible Top Urgent segment	Valid, privileged credentials are exposed right now	Commit capacity to Top Urgent before anything else. A valid credential is exploitable from the moment of exposure
A backlog concentrated in Not Urgent	Either genuinely low exposure, or unvalidated credentials whose status could not be determined	Verify that Secret Validation is enabled before trusting the shape. See When the backlog itself is unreliable
A large Urgent middle	Credentials whose validity or privilege is confirmed but whose containing repository is private	Plan scheduled rotation rather than an incident response

Select a segment to filter the table to that Urgency level.

The SLA widget — how much of the backlog is already late.

The SLA widget charts open issues by SLA status. An overdue population is a commitment already broken, independent of Urgency. Read the SLA widget alongside the Urgency widget: overdue issues at a low Urgency level are a process problem, while overdue issues at Top Urgent are an escalation.

Note: The Urgency widget and the SLA widget describe the backlog. The Insights widget builds the rotation queue and belongs to the next stage.

Caution: Backlog age carries a different meaning for a secret issue than for a vulnerability issue. A vulnerability becomes more dangerous as exploit intelligence matures. An exposed credential is fully exploitable on day one, and every additional day is additional exposure window. Do not read an old secret issue as a stale one.

Prioritize

Prioritize by Urgency, and use Severity as the tie-breaker within an Urgency tier. Severity rates the credential class in isolation; Urgency rates the credential in your environment by adding the validation status, the visibility of the containing repository, and the privileges the credential grants.

Use the Insights widget. Each insight card pairs an Urgency level with a second risk dimension and states how many issues satisfy both conditions. Selecting a card applies both filters to the Secrets table. unverified — confirm the insight card count and the dimensions the Secrets table defines

Start with the cards that combine the highest Urgency level with either a validated credential or a public repository. Those two conditions together describe a credential that an attacker can read and use immediately.

When no card fits the objective, sort the issue table by Urgency in descending order, then sort by Severity within each Urgency tier.

Note: For the complete secret metric table and the Urgency model, see Urgency. For the column and filter model of the table itself, see Understand the Secrets table.

Investigate

An Urgency level tells you an issue ranks highly. It does not tell you what the credential unlocks, or what the rotation will cost. Investigation answers three questions, and each answer changes the action you take.

Can an attacker use this credential?

A high-entropy string that resembles a credential but authenticates nothing is a false positive. A validated credential in a public repository is an active compromise.

The Urgency Details section in the issue side panel supplies the usability evidence: the Validation status of the credential, the Repository Visibility of the containing repository, the privileges the credential grants, and whether the credential appears in Git history in addition to the current file state.

Evidence	Consequence
Validation is Privileged	The credential authenticates and holds elevated permissions. Treat as an incident, rotate immediately, and review provider audit logs for use
Validation is Valid, repository is public	The credential authenticates and is publicly readable. Assume compromise and rotate ahead of the SLA deadline
Validation is Valid, repository is private	The credential authenticates but the exposure is bounded by repository access. Rotate on the SLA schedule
Validation is Invalid or Irrelevant	The credential does not authenticate. Remove the value, but no rotation is required
Validation is unavailable	Secret Validation is not enabled, so usability is unmeasured. Treat as potentially valid rather than as low risk

Note: High-entropy detections are excluded from Urgency escalation, because entropy-based rules generate a high rate of false positives. An entropy detection that returns a Valid validation status is the exception, and warrants the same response as any other valid credential.

What is exposed if the credential is used?

Blast radius determines the escalation level and how much capacity the issue justifies.

The Urgency Details section reports the privileges the credential grants, the systems the credential authenticates against, and the Number of Occurrences of the same secret hash across the environment. The occurrence count is the secret-specific multiplier: one credential committed to a shared configuration template propagates into every repository that copied the template.

An existing network control that restricts where the credential can be used from reduces the exposure but does not remove the exposure. Record the control, and keep the issue open against the rotation.

Who owns the rotation, and what does the rotation cost?

The code evidence names the repository, the branch, the file path, and the commit that introduced the credential, along with the commit author. That identifies the team to route the work to and the file to change.

The rotation blast radius determines the cost. A credential used by one service is a rotation and a single redeploy. A shared credential used across many services requires a coordinated rotation, because rotating the credential breaks every consumer that still holds the old value. Establish the consumer set during the investigation, because the consumer set — not the credential itself — drives the rotation timeline and determines whether the work needs a Case.

Two conditions that understate impact

• Validation not enabled. When Secret Validation is not enabled on the scanner, the Validation column is unpopulated and the Urgency engine cannot separate usable credentials from inert strings. The backlog appears less urgent than it is.
• History-only detection. A credential deleted from the working tree remains readable in commit history. When the GIT framework detects a credential that no longer appears in the current file state, the file evidence may show a clean file while the credential remains fully retrievable. Rotate regardless of whether the value is still present in the working tree.

Important: The Urgency Details section is populated for issues from periodic scans. PR scan issues and CI scan issues have no deployment context, because unmerged code is not deployed. For PR scan and CI scan issues, prioritize by Severity and by validation status.

---

Remediate

Open the Resolution tab in the issue side panel. The Resolution tab presents the remediation paths available for the issue.

Remediation for a secret issue is always two actions in a fixed order. Rotate first, then remove. Removing the value first leaves the live credential in circulation with no open issue tracking it.

Path	Use when
Rotate at the issuing provider	Validation is Valid or Privileged, or validation is unavailable. Always the first action. Invalidate the exposed credential at the provider that issued it, then confirm the old value no longer authenticates
Replace with a secrets manager reference	Always, after rotation. Replace the hardcoded value with a reference resolved at runtime, so the new credential never enters the repository
Remove the value from Git history	The credential reached a remote and the repository is public or widely accessible. Deleting the value in a new commit does not remove the value from history
Mark as a false positive	Validation is Invalid or Irrelevant and the string is not a credential. Record the determination in the resolution comment, and tune the detection rule if the pattern recurs

Sequence within an Urgency level by rotation leverage. Among equally urgent issues, the credentials with the highest Number of Occurrences resolve the most issues per rotation.

Escalate to a Case when the credential is shared across services and the rotation requires coordinated redeployment.

Caution: Setting a secret issue to Resolved records a triage decision. Setting the status to Resolved does not invalidate the exposed credential. Confirm rotation at the provider before resolving, and record the rotation in the resolution comment.

Note: For rotating credentials from the development environment and replacing hardcoded values with secrets manager references, see Cortex Cloud IDE extensions.

---

Prevent

A rotated credential that the next commit reintroduces has not been resolved. Close the loop with a Unified Application Security Policy that blocks the secret pattern at the earliest enforcement point.

Select the trigger in shift-left order: a PR Scan trigger blocks the credential before the code merges, and a CI Scan trigger blocks the affected artifact before deployment. Align the policy grace period to the Urgency level — shorter grace periods for issues that reach Top Urgent, longer grace periods for issues that remain Not Urgent.

Prevention carries more weight for secrets than for any other issue type. For a vulnerability, blocking at the pull request avoids a later upgrade. For a secret, blocking at the pull request avoids a rotation entirely — a credential that never reaches a remote never needs to be invalidated. Set the PR Scan trigger to block rather than warn for the Secrets finding type wherever the branch is production-bound.

Extend detection into Git history. Enable Git History Scan so that the policy evaluates commit history in addition to the current file state, which closes the gap where a deleted credential remains retrievable.

Note: For policy triggers, actions, conditions, and grace period configuration, see Unified Application Security policies. For the SECRETS and GIT detection rules the policy evaluates, see Application Security Rules rules.

When the backlog itself is unreliable

Two conditions distort the secret backlog, and both resemble low risk rather than reduced visibility.

Validation is not enabled. Without Secret Validation, the Urgency engine cannot separate usable credentials from inert strings, and the backlog concentrates in the lower Urgency levels. Enable Secret Validation on the scanner and re-triage after the next periodic scan.

Git history is not scanned. Without Git History Scan, a credential deleted from the working tree produces no finding while remaining fully retrievable from history. The absence of an issue is not evidence that the credential was never exposed. Enable Git History Scan and treat the first scan after enablement as a discovery pass rather than as a regression.

Treat both settings as prerequisites to trusting the Urgency distribution across the secret backlog.