You can find leaked secrets by installing the Safeguard CLI, signing in, and scanning a working tree on your own machine. The local runner executes the job locally and uploads only the SBOM and findings, not your source. You then triage results in the Secrets dashboard, where issuer-specific hits are verified.
What does the local runner actually do?
The runner is part of the Safeguard CLI, not a separate product. After you sign in, it polls the platform for scan jobs assigned to your machine, runs each one with a local scan server, and sends back the result files and job status.
Every connection is outbound HTTPS opened by the runner. Nothing connects inbound to your laptop or build host. According to the runner documentation, the SBOM and findings are uploaded and your source code stays where it is.
That matters for secrets work in particular. A leaked key sitting in a repository is exactly the kind of material many teams do not want copied to a third party for analysis.
How do you install it and sign in?
On macOS or Linux the installer is a one-liner from cli.safeguard.sh, and Windows has a PowerShell equivalent. If you prefer to read before you run, download the script to a file first and open it. You can pin a version with the SAFEGUARD_VERSION variable. The installer checks the release checksum before placing the binary on your PATH.
Then run safeguard login, which uses the OAuth 2.0 device flow. You approve the session in your browser and the CLI picks up the token.
Running safeguard with no arguments opens the interactive session. Use /login there if you prefer to stay in the terminal. The first run downloads scanner tools and the vulnerability database, so expect a short wait.
How do you scan for secrets?
There are two routes, and both are documented.
First, a normal scan: safeguard scan pointed at the current directory builds the SBOM and matches it against advisories. The CLI page notes that secrets are computed as part of a local scan, and in pipelines each component gets a secret.json file next to its SBOM and vulnerability output.
Second, the detector: the Secrets Scanning docs describe a safeguard detect command with a secrets option for scanning a working tree. Check that page for the exact flag in your version.
Either way, the scanner looks for issuer-specific patterns for more than 200 cloud, SaaS and identity providers, plus generic shapes such as private keys, JWTs, bearer tokens and connection strings. High-entropy strings are flagged and classified to cut noise from hashes and UUIDs. You can add internal token formats in .safeguard/secrets.yaml.
What do the severities mean?
For issuer-specific findings, Safeguard makes a low-privilege call to the issuer to see whether the credential is live. Unverified matches are still raised but marked unverified, and you can switch verification off per issuer, for example in air-gapped environments.
- Critical: a verified, high-privilege credential.
- High: a verified, lower-privilege credential.
- Medium: an unverified match for a known issuer.
- Low: a generic or entropy-based finding.
Work the list top down. A verified cloud admin key is an incident. A low entropy hit in a test fixture is a cleanup ticket.
Where do you review findings?
Use the Secrets dashboard in the web app. It shows counts and trends by issuer, time to revoke, leaked and revoked versus leaked and still open, and a heatmap of git history. The docs state there is no CLI command yet for listing, revoking or rotating secret findings, so the dashboard is where that work happens. They also say there is no CLI command yet for installing a git hook.
Scans cover the current code at HEAD, and the docs describe deep scans of git history on connect and on demand. History matters because deleting a secret from the latest commit does not remove it from the past.
What to do
- Install the CLI, reading the installer first if your policy requires it.
- Run
safeguard loginand confirm withsafeguard whoami. - Scan one repository from its root with
safeguard scanand look at the secrets output. - Open the Secrets dashboard and sort by verified findings.
- Revoke and rotate at the issuer first. Remove the string from code second.
- Add a custom pattern in
.safeguard/secrets.yamlfor internal token formats. - Rerun the scan, and run it again in CI so the same key cannot come back unnoticed.
The runner also has safeguard runner status, which shows whether it is registered and what it is doing, and safeguard runner stop, which drains in-flight work before stopping.
Try it
Open the full version at /demos/secrets-scanning.
Quick check
Does my source code leave my machine?
Per the runner documentation, the runner uploads the SBOM and findings and keeps source code local. The page does not say whether logs or tool output are also sent, so check with your admin if that matters to you.
Can I list or rotate secrets from the CLI?
Not yet. The docs say there is no CLI command for listing, revoking or rotating secret findings. Use the Secrets dashboard and rotate at the issuer.
Sources
Last reviewed: 18 October 2026.
