How to handle secrets that appear in scanner output

If a scanner report displays a plausible live secret, start an exposure response and inspect the output-control boundary. A deliberately restricted secret-response view differs from an ordinary report or broad notification; determine whether distribution exceeded the intended audience while containing further copies. Limit access to the report, notify the secret owner through the approved incident channel, revoke or rotate the credential, and trace where the output was copied. Redact and repair the report path without destroying the evidence needed to understand the incident. Do not paste the value into a ticket to prove that it exists. If the string is a test fixture or already invalid, document how that was established before closing the exposure case.

The response depends on what appeared, where, and who could view it. A credential visible only in a tightly restricted scan result has a different distribution from one copied to email, chat, CI logs or an executive summary. Neither case is made safe by merely deleting the source file. OWASP's secrets guidance calls for prompt response to exposure, revocation and an inventory of where secrets are visible; its logging guidance lists access tokens, passwords, connection strings and encryption keys among data that should not be directly recorded.

A redacted illustrative incident

Invented case; the marker below is not a usable credential. A scanner reviews Juniper API at pinned revision JA-71. Its finding about a configuration file includes a source excerpt. The rendered report shows Authorization: Bearer [synthetic token placeholder]. A developer sees the report in the security portal; the report service has also sent a notification containing the first 300 characters of the finding. The AppSec lead does not yet know whether the original value is live, which notification recipients saw it, or whether error logs kept the same excerpt.

Two work streams begin together. The credential owner evaluates and rotates the underlying secret. The report owner contains and traces output copies. Waiting for perfect confirmation of validity before any containment could leave a usable credential exposed. At the same time, the team should avoid broad claims such as “the secret was publicly leaked” without evidence of public access.

Use an incident ledger with references, not the secret:

The token itself is not needed in this ledger. A short, non-reversible internal reference or provider credential ID can help the owner identify it without another disclosure. Be careful with raw hashes: low-entropy secrets or known formats can make a hash an unsafe substitute, and a copied hash can itself become a correlating identifier.

Contain the output and the credential

Assign one coordinator so the credential and report work do not fall between teams. The sequence is:

1. Restrict new distribution. Prevent further notifications, exports and previews of the affected excerpt. Limit the existing report to the minimum authorized responders. Preserve a source-free incident record with timestamps and report IDs.
2. Identify the credential owner. Use the service, environment and provider metadata already available to the team. Do not copy the value into a broad search, chat message or ticket. If ownership is uncertain, use the security incident route rather than guessing a developer from a code blame line.
3. Revoke or rotate. Coordinate replacement for dependent services. The owner should verify the old credential's status using the provider's administrative controls and confirm the replacement supports intended operations. GitHub's secret-scanning guidance advises immediate rotation of an exposed credential; removing it from history alone does not revoke it.
4. Find known copies. Trace portal records, rendered PDFs, CI output, notifications, ticket integrations, object versions, logs, analytics, support exports and backup retention. Record who had access and whether a copy was delivered. A deletion from the primary report does not establish deletion from those other places.
5. Repair the producer. Make the scanner/report pipeline store and render a sanitized finding: type of secret, affected path and line reference, risk explanation, and a limited fingerprint or provider identifier where appropriate. A technical responder can use a separately authorized source-view path if needed; routine reports do not need verbatim values.

This is a workflow, not a command to rewrite every record immediately. An incident responder may need to preserve restricted evidence for investigation, while ordinary readers must no longer receive it. Coordinate retention, legal hold and deletion with the organization's policy. Do not claim physical erasure from a redaction or primary-file deletion.

Trace copies as a graph with delivery states

Juniper's incident initially names a portal report and a notification job. The output owner now maps the actual branches using references only:

finding R204
  ├─ portal record P1: accessible to 4 authorized responders
  ├─ notification N8: queued, not delivered
  ├─ export X3: generated, downloaded by 1 authorized analyst
  └─ diagnostic event L9: excerpt field present, restricted log store

The counts and objects are invented. They illustrate why “two places redacted” is an inadequate closure claim. Cancelling N8 can prevent delivery if queue state proves it never left. Replacing X3 cannot recall the analyst's downloaded copy. Restricting L9 changes future access but does not establish who accessed it earlier. Access permission, actual delivery and actual viewing are different facts.

A filled action record could read: “N8 cancelled before dispatch, P1 sanitized, X3 replaced and recipient handling requested through the incident process, L9 restricted pending the approved integrity-preserving redaction procedure.” The downloaded copy remains in the ledger until its handling is evidenced or a retention exception is documented. Do not paste the secret into the request asking someone to delete it.

Preserve a useful finding without the value

The normal report should carry a deliberately small projection:

{
  "incident_reference": "SECOUT-14",
  "credential_reference": "provider-key-K7",
  "location": {"path": "config/partner.conf", "line": 18},
  "credential_status": "revoked; owner evidence attached separately",
  "impact": "Possible use of the credential's partner API permissions; misuse not established",
  "evidence": "Restricted source reference; credential value omitted"
}

provider-key-K7 is a fictional provider identifier, not a token or a hash of one. The finding remains useful: developers know where the credential entered source, what to remove and which owner invalidated it. Routine email and executive exports can use an even smaller projection without source paths. A free-text excerpt should not be the default field copied into every output.

The repair belongs before durable fan-out. If the database stores a raw excerpt and the portal alone masks it, the notification worker or export renderer can still leak the original. Keep any necessary raw incident evidence in the separately authorized restricted path, and make ordinary consumers use the sanitized representation. Review exception logs and serializer failures too; an error handler dumping the rejected object can recreate the exposure.

A backup restore must not resurrect the report

Suppose a retained backup still contains the old raw report. Deleting the live copy does not qualify restore behavior. The incident record should identify the retained version and require a restore procedure that reapplies access restrictions and redactions before exposing restored content to ordinary users. If that procedure has not been checked, record restore handling as outstanding rather than claiming all copies removed.

Credential validity is a separate axis. Provider evidence that K7 is revoked closes its future-use branch; it does not establish that the exposure window had no use or that copied text vanished. Conversely, sanitizing every known output does not revoke a still-valid credential. OWASP's secrets lifecycle guidance distinguishes revocation from removal, and GitHub advises prompt credential rotation after an alert.

The source-secret incident and scanner amplification should remain linked but distinct. A token-shaped string is still only a candidate until its nature is established. No credential operations, notifications or restore exercise were performed for this article.

Validate the fix at both boundaries

The AppSec lead closes the incident only after receiving two sets of evidence. For the credential: the owner records provider-side revocation or expiry, checks for suspicious use in the relevant window as available, and confirms dependent services use the replacement. For the output: the report owner verifies that future findings use redacted fields and that each known durable copy has been addressed or has a documented, bounded retention exception. A manual check with a synthetic marker can confirm that report, notification and export surfaces do not reproduce a value; it should not place a live secret into another scan.

Here is an invented compact closure line for a later point when the downloaded export, diagnostic record and restore procedure have also been addressed:

SECOUT-14: credential owner confirmed old credential invalid at 16:05 UTC and replacement service operation at 16:14 UTC. Portal and diagnostic copies were sanitized; the queued notification was cancelled before delivery; export-recipient handling was evidenced. One backup version remains under the declared retention schedule with restricted restore access and a procedure that reapplies redactions before ordinary access. No evidence of unauthorized use was found in the provider logs reviewed for the stated window. Logs outside that window were unavailable. Report rendering at the selected new revision omits the synthetic marker's value.

That line reports evidence and limits. It does not promise zero use or instant deletion from backups. If the old credential cannot be invalidated, keep the incident open and escalate the compensating access restrictions.

Distinguish containment from a corrected distribution design

Juniper can redact R204 and still repeat the incident on the next finding if every renderer receives raw excerpts by default. Inspect the data contract used by ordinary portal, notification, and export consumers. The sanitized finding should be the normal input to those consumers; restricted raw evidence should require a separate authorized path.

For each consumer, review its fallback behavior. A missing sanitized summary should not cause the notification worker to substitute the first 300 characters of the raw model output. A serialization failure should not dump the rejected record into broad diagnostic logs. The source of truth for ordinary delivery needs to remain the reviewed projection even when the happy path fails.

The incident coordinator can close immediate containment before every architectural improvement is deployed, provided the status states that distinction and the remaining owner is named. Credential invalidation, known-copy handling, and future-output prevention are separate work items. None should disappear merely because the portal looks redacted.

A later synthetic-marker check should follow the same fan-out branches that created SECOUT-14, including error and retry paths where applicable. It supplies bounded evidence about the repaired output contract. It cannot establish that no unknown historical copy exists, and the closure note should retain the actual inventory and retention limits.

For the next scan rollout, make the source-free incident ledger and output-copy inventory part of the response playbook. Use what a useful vulnerability finding should contain to preserve the security decision without raw secret text, and how to verify a fix at a new commit to check the sanitized report path after it changes.