On this page

Last updated: May 23, 2026

Secret Exposure Detection

Secret Exposure Detection finds likely secret leaks in the configuration and public runtime responses of your own services. The goal is simple: catch the moment someone pastes an API key, a database URL with credentials, or a private key into a public client variable, build-time surface, exposed config response, debug endpoint, or similar runtime surface.

What gets scanned

Today, Secret Exposure Detection scans two bounded surfaces of your own services:

  • Service configuration: environment variable names, selected Dockerfile build-time keys, and high-confidence value patterns that appear in public/client variables.
  • Public runtime HTTP responses: the same fixed safe route set used by Service Scans, classified in memory for high-confidence secret patterns.

Scanning is scoped to custom services you own. Service catalog internals are not scanned for secrets the same way; the catalog manages its own secrets and exposing them would be a platform-level issue Guara handles directly.

What “exposure” means here

Exposure detection looks for three classes of issue:

  1. A high-confidence secret pattern in the wrong place. A value that matches a well-known secret format (an obvious access-token shape, a connection URL with embedded credentials, a private key block, etc.) appearing as the value of a variable that isn’t named like a secret.
  2. A naming/value mismatch. A variable named like a non-secret (API_URL, PUBLIC_TOKEN, DEBUG_NOTE) carrying a value that looks like a secret.
  3. A public runtime response leak. A bounded HTTP response from a safe public route contains a high-confidence private key, GitHub token, Stripe secret key, Slack token, credential-bearing URL, or public client config containing one of those patterns.

We favor deterministic, explainable detectors over broad regex sweeps. Every detection in the v1 set has a specific, named rule, with no opaque pattern-matching that fires without explanation.

What never happens

  • The raw secret value is never persisted. Not in the finding, not in the event, not in logs, not in traces, not in metrics.
  • Raw runtime response bodies are never persisted. Runtime checks classify bounded responses in memory and store only redacted route, detector, family, and exposure-vector metadata.
  • The raw value is never displayed in the dashboard. Evidence is redacted to a short fingerprint (e.g., a length and a non-reversible prefix tag) that lets you identify which value triggered the detection without revealing it.
  • The raw value is never sent to an AI explanation or any third-party. When you ask for an Explain This Threat on a secret finding, the explanation works from redacted evidence only.
  • There is no “view the secret” button. If you need to see the value, look at the variable directly in your service settings.

If a detector cannot describe a finding without revealing the secret, the detector doesn’t ship.

What a finding looks like

A secret exposure finding tells you:

  • Which service has the suspected exposure.
  • Which variable holds the value (the name only).
  • What kind of secret it looks like (e.g., “high-confidence private key block”, “URL with embedded credentials”), without quoting the value.
  • A redacted fingerprint of the value, only enough to tell two findings apart.
  • Concrete remediation guidance.

Severity scales with the confidence of the pattern and the surface where it appears.

How to fix one

Most fixes follow the same shape:

  1. Rotate the secret. Assume the value is no longer confidential the moment it appeared in a place it shouldn’t have. Guara may have detected it, but other tools (your CI logs, your screen during a paste, whatever) may have too.
  2. Move the value to a properly-named secret variable in your service. For secret storage on Guara Cloud, see Environment variables.
  3. Resolve the finding. The next scan pass will confirm the value is gone.

If you can prove the value was a placeholder or a test fixture that doesn’t grant any real access, mark the finding as false positive so the detector can be tuned.

Scope and confidence

Secret Exposure Detection observes platform service configuration and public runtime HTTP behavior. Source-code repository scanning lives outside this surface area. Treat Secret Exposure Detection as a high-confidence floor for the surfaces it covers, and pair it with your own secret hygiene practices upstream.

When scans run

Like Service Scans, Secret Exposure Detection runs in the background. You don’t trigger it manually. When it finishes a pass on a service, it emits a secret_exposure_scan_completed event on the Security Events timeline.

Where to go next