> 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/code-security-scanners/secrets-scans/investigate-and-remediate-secrets-issues.md). # 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](/application-security/application-security-posture-management-aspm/urgency.md). For the column and filter model of the table itself, see [Understand the Secrets table](/application-security/code-security/code-security-scanners/secrets-scans/understand-the-secrets-issues-table.md). ## 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](/application-security/application-security-posture-management-aspm/unified-application-security-policies.md). For the `SECRETS` and `GIT` detection rules the policy evaluates, see [Application Security Rules](/application-security/application-security-posture-management-aspm/application-security-rules.md) 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. --- # 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/code-security-scanners/secrets-scans/investigate-and-remediate-secrets-issues.md?ask=&goal= ``` `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.