ProductSecret Scanning
Secret scanning for exposed API keys and tokens.
Find keys and tokens left in code, documents and messages. Review their locations and check whether supported keys still work at the issuer. Assign an investigator and track the response from the same finding.
- AppSec engineer
- Developer
- Service owner
Who does the work
The people this feature hands work to, and what each of them does with it.
AppSec engineer
Connects sources, tunes what counts as a match and reviews findings that need a human verdict.
Developer
Removes the key from code or history after a pull request check flags it.
Service owner
Replaces or revokes the key at the issuer, then waits for the recheck.
How to read one finding
Read the evidence in order instead of treating every match as a confirmed incident.
01
A selected source contains a value that matches a credential rule.
02
The finding records the type and location for review.
03
A supported type receives an issuer-side validity result and check time.
04
A person checks context, assigns the response and changes the key at its issuer.
See what a detected key tells you.
This fictional AWS key was found in a GitHub repository. Review the recorded location and issuer-check result before deciding who needs to respond.
- A detection records where the value appeared.
- An active result means authentication worked at the check time.
- The owner checks dependent services and replaces or revokes the key at AWS.
Where and when Cremit scans
Cremit checks the sources connected to your organization. External asset discovery and monitoring follow separate organization settings.
- Repositories and Git history
Connected GitHub, GitLab and Bitbucket repositories are scanned for keys in code and commit history. Removing a value from the latest file does not remove earlier commits.
Connected GitHub pull requests can be checked when the GitHub App receives their events; repository history scans run on a schedule.
- Packages and cloud storage
Connected GitHub Packages or GHCR images and AWS S3 objects can be checked for exposed credentials.
The applicable permissions and scan schedule determine what is covered.
- Documents and messages
Connected Google Drive, Jira, Confluence, Notion and Slack content can be scanned for credential-like values.
These sources are checked on a schedule, not at every edit or message.
What a scan result can tell you
Detection, validity and evidence of actual use are different claims. Keep their basis visible when handing off a finding.
Pattern match
A rule identified a value that looks like a credential and records where it was found. Review context and possible false positives before treating it as a usable key.
Issuer check
For supported credential types, the latest check can indicate whether the key works at its issuer. Review the result and time; unsupported or inconclusive types need manual review.
Response decision
Use exposure location, latest validity and available ownership or AWS/GCP permission context to decide urgency. The responsible person rotates or revokes the key at its issuer and verifies the outcome.
Common questions
If a secret is removed from the latest commit, is the exposure gone?
No. It may remain in Git history or other copies. Review the recorded locations and rotate or revoke a sensitive key at its issuer.
Are all detected keys checked automatically?
No. Issuer-side validity checks are available only for supported types. Other findings remain for manual review, and a prior result may become stale.
Does a live result prove the credential was misused?
No. It shows the result of a validity check at a point in time. Investigate issuer activity logs and other incident evidence to assess use.
Continue the investigation
Once you have a match, compare exposure with the latest validity and available access evidence. The false-positive guide explains how to review ambiguous findings.