Secret findings

Security → Secret Findings (/gravity/security/secret-findings) lists credentials and API keys that Sencai’s secret scanner detected in your Git repositories.

What’s scanned

Every push to a repository managed through Sencai’s Git integration is scanned for patterns that look like leaked secrets (API keys, tokens, and similar). A finding is created automatically when a match is detected.

Caution

Push-triggered scanning has to be turned on for your environment before any findings appear here. If this screen is empty and you expect findings, ask your account team to confirm scanning is active rather than assuming nothing has leaked.

Detection is pattern-based: it looks for the shape a secret typically takes (a cloud provider’s key format, a token prefix, and similar recognizable patterns) in the diff of what was pushed, not a general text search. That means it can miss a secret that doesn’t match a known pattern, and can occasionally flag something that looks like a secret but isn’t - that’s what Mark False Positive is for.

Severity and confidence

Findings are labeled Critical, High, Medium, or Low, based on the type of pattern matched and how confident the scanner is that it’s a real secret rather than a false match. The stats banner at the top of the page shows how many open findings are Critical, High, or from the last week, so you can see at a glance whether anything urgent needs attention.

Reading the table

Column	Meaning
Repository	Which repo the finding was detected in
File	The file and line number the match was found on
Rule	Which detection rule matched
Severity	Critical / High / Medium / Low
Status	Open, Acknowledged, False Positive, or Resolved
Detected	When the push that triggered the finding happened
Acknowledged by	Who acknowledged it, if anyone

Expand a row to see the commit SHA (linked to the commit in your Git repository, when available), the full file path, and a notes field you can use to leave context for your team.

Response workflow: rotate first, then resolve

A leaked credential is exposed the moment it’s committed, even if you remove it in a later commit - anyone with repository access at any point in its history can see it. Treat a genuine finding as follows:

1. Rotate the credential at its source first - regenerate or revoke the exposed key or token with whatever service issued it (your cloud provider, a third-party API, and so on). This is the step that actually closes the exposure; nothing in Sencai does this for you automatically.
2. Then update the workflow in Sencai:
   • Acknowledge - marks the finding as seen and under review; you can add a note when you do.
   • Mark False Positive - use this if the match wasn’t actually a secret (a test fixture, an example value, and so on).
   • Resolve - marks the finding as closed once you’ve rotated the credential and confirmed it’s no longer a risk.

Resolving a finding without rotating the underlying credential first doesn’t do anything to the credential itself - it only changes the status shown here.

Caution

Treat every open finding as a real, live credential until you’ve confirmed otherwise - the cost of rotating a secret that turns out to be harmless is far lower than the cost of leaving a genuinely leaked one in place while you investigate.

What’s next

• Git integration - where these push-triggered scans run
• Vulnerabilities - a different kind of finding: known CVEs in container images
• Audit log - every acknowledge/resolve decision is recorded there