Stable identity
A finding's fingerprint is built from the rule, path and a hash of the value, so re-scans update the same finding instead of creating new ones.
Find exposed secrets.
Keep their context.
Detect secrets across source, history and artifacts. Trace each finding to its location and evidence so your team can investigate and remediate.
Repository review
Configuration file
Credential pattern
Value redacted
Investigation context
01 / Locate
Find the credential without repeating it.
- File reference
- Secret category
Keep the secret value out of the demonstration; the source location gives the team a place to start.
02 / Review
Understand what needs rotation.
- Service context
- Responsible owner
Investigate the finding and confirm which service and owner are affected.
03 / Remediate
Rotation comes before closure.
- Rotation task
- Verification record
Coordinate removal and rotation, then verify the source with another scan.
History
Not just HEAD
Working tree, git history, image filesystem.
Masked
At the scanner
No raw value on the finding.
Opt-in
Live validation
Off by default; never from the scanner.
CWE-798
Tagged
Hard-coded credentials.
The category
What is secrets detection?
Secrets detection combines provider-specific patterns, which recognise the format of a particular issuer's key, with entropy checks for random-looking strings that match no known format. The hard parts are history and noise: a key removed from the latest commit is still in the repository, and test fixtures full of example keys can drown the real one.
SecurityVault treats a leaked secret as an exposure to close, not a line to delete. Each finding is tied to the commit that introduced the credential and, when a key is baked into an image, to that image digest and the workloads running it, on the same graph that runs from code to artifact to cloud. With your opt-in, a live key is ranked above a dead one, and a fail-closed gate stops the next one at the pull request. You know what to rotate first and where the old value is still readable.
Repository location
Locate the credential without spreading its value.
Finding context
Keep the source reference available for investigation.
Remediation review
Track the response and supporting verification.
Removing a string from a file does not, by itself, revoke a credential.
How SecurityVault does it
How does SecurityVault detect secrets?
Working tree
The native secrets engine applies provider fingerprints and entropy heuristics to every file in the checkout. It is passive: it never sends a candidate anywhere, and it never emits the full value.
History
A walk of the repository's git history scans only the lines each commit added, oldest first, so the first occurrence is the earliest commit. The same secret committed many times becomes one finding with a commit count, and a secret already reported at HEAD is not reported twice.
Images
Image scans unpack the filesystem and run the same secrets engine over it, so a key baked into a layer is found even when the source repository is clean.
Open source
gitleaks and trufflehog run on every repository scan alongside the native engine. Results that agree resolve to one finding.
Validation
With your opt-in, the platform checks whether a credential is still accepted by its issuer, using a pinned endpoint per provider and a read-only identity call. Each attempt is recorded without the secret. A live key is ranked up; a dead one is ranked down. The isolated scanner never becomes a credential oracle.
After the scan
What happens to a secrets finding?
It is attached to the repository and commit where it was found and, when found in an image, to that image digest and the workloads running it.
Finding
affects
Repository
contains
Commit
triggered
Build
produces
ContainerImage
runs_image
Workload
01
02
Suppression with a reason
Inline suppression needs a written justification, and every suppression is published with the scan result for review.
03
Closed by evidence
Record credential revocation or rotation separately from scan results. A clean rescan alone does not prove that an exposed credential stopped working. Human dispositions require a reason code and are never written by AI.
Gates
Can a committed secret block a pull request?
Yes, and catching it there is the cheapest moment, before the value reaches a shared branch or an image. The pull-request or pipeline gate evaluates secrets findings with the rest of the scan against your severity threshold and policies, and a scan that fails or times out is a deny, never a silent pass. The developer sees the masked finding on the pull request as SARIF or a comment, and every comment attempt is recorded. See deployment gates and what to do when a secret is found.
Detected secret
Identify the source finding in the change.
Organisation policy
Evaluate the finding against the configured gate.
Pull-request result
Return the decision with its source context.
The developer can act at the point the credential is introduced.
Evidence
How do I prove a leaked credential was handled?
The record shows it. A history finding carries its first commit and commit count, an image finding carries the image digest, the validation log shows when the credential was checked and what the issuer answered. Add revocation or rotation evidence from the credential owner; absence from a scan is not proof of revocation. Secrets findings are recorded as secrets evidence when controls are evaluated, and the cross-walk maps that evidence across 6 seeded framework catalogues for your access-control and cryptography controls.
Source reference
Preserve where the credential was discovered.
Remediation action
Record the response taken for the exposed credential.
Review evidence
Retain the information supporting disposition.
The audit follows the response, not just the removal of text.
FAQ
Frequently asked questions about secrets detection
- Does SecurityVault store the secrets it finds?
- No. The value is masked inside the isolated scanner before anything leaves it, evidence snippets are trimmed, and a finding's identity is built from a hash of the value. The raw secret is never stored with the finding.
- Will a secret deleted in a later commit still be found?
- Yes, when the scan includes git history. The history pass reads the lines added in each commit, so a key committed and then removed is still reported, once, with the number of commits it appeared in.
- Does SecurityVault test whether a secret is live?
- Only if your organisation opts in; it is off by default. When enabled, the platform makes a read-only identity call to the issuer's own endpoint, rate-limited per organisation, and records live, dead or unknown. The scanner itself never contacts a provider.
- How do I mark a test fixture as safe?
- Add an sv-ignore annotation with a written reason next to the line. A bare marker without a reason suppresses nothing, and each suppression is recorded with its rule, path, line and reason.
- What should I do when a secret is found?
- Rotate it first, then remove it from the code. Deleting the line does not revoke the credential, and the old value stays readable in git history and in any image layer that already shipped it.
Secrets scanning runs in the same scan as SAST and IaC security, which flags credentials hard-coded in CI workflow files, and container image scanning finds keys baked into layers. Built for developers, who see the finding in their own pull request, and AppSec teams, who own the rotation. Glossary: secrets detection, credential, secret.
From the blog
Further reading
- Security logging: test what leaves your applicationReview security logging with synthetic secrets, export-path checks and failure tests while preserving useful evidence for incident investigation.
- Secret rotation: verify every consumer switchedPlan secret rotation around consumer inventory, controlled cutover and revocation evidence so an updated secret does not leave old credentials usable.
- Leaked secret response: rotate, trace, then prevent repeatsDeleting a leaked secret from HEAD is not remediation. The response that works: rotate first, trace affected images, keep evidence and gate repeats.
- Secrets detection beyond HEAD: git history, CI logs, imagesSecrets detection that only scans HEAD misses real leaks. Where credentials hide in git history, CI logs and image layers, and how to verify them safely.
See it on your stack
Look beyond the latest commit.
See how history scanning surfaces potential credential exposures, with masked evidence and context for investigation.