The Safeguard CLI detect command scans files for hardcoded secrets, API keys, tokens and some misconfigurations using pattern matching and static analysis. It redacts values in its output by default, can filter by severity, and writes table, JSON or SARIF. A finding means rotate the credential, not just delete the line.
Run it
safeguard detect --path .
By default it scans recursively, looks for secrets and misconfigurations, skips common folders such as git metadata, node modules, vendor and virtual environments, and skips some binary file types. Those defaults come from the help text of the build we checked.
Limit the detection types if you only want secrets:
safeguard detect --path . --detect secrets
Control the noise
Useful options in the help text and docs:
safeguard detect --path . --severity high --exclude-dir testdata --format sarif --output detect.sarif
- The severity option sets a minimum level.
- Exclude options skip patterns, folders and extensions.
- A maximum file size option skips very large files.
- A workers option changes parallelism.
- A verify option attempts to verify detected secrets. Read what that does in your build before using it, since checking a credential means contacting a service.
Custom rule files are listed in the help text as not supported yet, and are rejected if set.
Redaction
Values in the output are redacted unless you pass the option that turns redaction off. Keep it on in CI. If you must see the value during an investigation, write the result to a private file and delete it after.
Exit codes
The documentation says detect returns 0 when the scan ran, regardless of findings, and non-zero only when the command fails. So a pipeline will not stop on a found secret by itself. Check the output file, or use your platform's gates.
What to do when it finds a secret
Deleting the line does not fix it. The value is still in your git history, and in every clone.
- Revoke or rotate the credential at the source. This comes first.
- Check the provider's logs for use you do not recognise.
- Replace the value in code with a reference to a secrets manager or an environment variable.
- Remove it from history if your policy requires that, remembering that rotation matters more.
- Add a pre-commit or CI check so it does not come back.
Where false positives come from
Test fixtures, documentation examples and sample keys trigger matches. Exclude those folders explicitly rather than lowering the severity, and write down why, so the exclusion gets reviewed later.
Pair it with a pre-commit habit
Detect is quick enough to run on a developer machine before a push. A local run catches the mistake before it reaches a shared branch, which is far cheaper than cleaning up after a leak.
Quick check
I removed the secret from the file. Am I done?
No. It is still in git history and in clones. Rotate or revoke the credential first, then clean up.
Will detect fail my build when it finds a secret?
Not through its exit code. It returns 0 when the scan ran. Check the output file or enforce with platform gates.
Safeguard also offers a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
