How do you find and handle leaked secrets using Safeguard?

To handle a leaked secret, revoke or rotate it first, then find where it was used, then remove it from code and history. Scanning finds the leak; the Safeguard Chrome extension helps you ask about the findings from a browser side panel, but it is not a scanner itself. The scanning happens in the platform and tools.

What does the extension do?

The Safeguard extension for Chrome puts a chat in a side panel for people with a Safeguard account. According to its Chrome Web Store listing you can ask about your findings, projects and compliance posture, and answers draw on your account's open findings and affected projects. It can also attach files or screenshots. Page control is optional, off by default and set per tab, and irreversible actions need your confirmation.

The Gold Open Source extension is separate. It is a launcher for gold.safeguard.sh to look up a package, container image, CVE, AI model, MCP server or agent skill, with no account needed.

Neither one scans your repositories. For secrets, Safeguard has secrets scanning as part of the platform, and the demo below shows how it works.

Open the full secrets scanning demo

Where do secrets leak?

OWASP's Non-Human Identities Top 10 describes secret leakage as credentials ending up in source code, plaintext configuration files or chat tools. Add CI logs, container images, build artefacts and issue trackers. Past incidents show another route: build environments that hold secrets, which is why Codecov's 2021 advice for affected users began with listing the keys present in CI.

Why is removing the file not enough?

Version control keeps history. A secret deleted in a later commit is still in earlier ones, and in every clone and fork. Treat any secret that reached a shared repository, even briefly, as exposed.

The order of operations

Revoke first. If a key can still be used, someone may be using it. Rotate it at the provider before anything else. A new key plus an updated deployment closes the exposure window.

Then investigate. Check provider logs for use of the old key from places or times you do not recognise. Codecov's guidance for affected users included auditing how exposed tokens were used.

Then clean up. Remove the secret from code, replace it with a reference to a secret store, and rewrite history only if you must, knowing that rewriting does not recall copies. Rotation is what protects you.

Then prevent. Add scanning before commit and in CI, and prefer short-lived tokens. Both AWS and GitHub document ways to avoid long-lived cloud credentials in workflows.

What are common mistakes?

Rotating one key and forgetting that it was reused in another service. Deleting the secret and assuming the problem is solved. Rotating without updating the deployment, causing an outage and a temptation to restore the old key. Alerting a channel that includes the secret itself.

How can you use the extension in this process?

Once scanning has raised findings in your Safeguard account, the side panel is a convenient place to ask which projects are affected and what to do next, without switching tabs. Use it to ask questions, then act in the systems that hold the credentials.

What to do

1. Revoke or rotate the exposed secret at the provider now.
2. Check provider logs for use of the old credential.
3. Search every repository, CI log and container image for the same secret.
4. Replace it with a secret store reference or a short-lived token.
5. Turn on secrets scanning in commit hooks and CI.
6. Record the incident, the rotation time and the follow-up in your tracker.

Quick check

Sources

• Safeguard extension on the Chrome Web Store
• Safeguard downloads
• OWASP Non-Human Identities Top 10
• Codecov, security update
• GitHub Docs, OpenID Connect

Last reviewed: 18 October 2026.