Secrets Detection

Overview

Secrets Detection identifies exposed credentials—API keys, passwords, tokens, certificates, and other sensitive values—committed to your source code repositories. Fencer automatically scans your connected repositories and groups detected secrets by their hashed value, giving you a deduplicated view of every leaked credential across your codebase along with severity ratings and remediation statuses.

Prerequisites

• A plan that includes secret scanning.
• At least one source code repository connected (GitHub, GitLab, Bitbucket, Azure DevOps, Cursor Origin, or a generic Git repository).
• A completed code scan on that repository. Secrets are surfaced as part of the code scanning pipeline.

How it works

When a code scan runs against a repository, Fencer checks the code for patterns that match known secret formats. Each detected secret is hashed for deduplication—if the same credential appears in multiple files or repositories, it is grouped into a single Secret record rather than creating duplicates.

Every Secret is linked to an underlying vulnerability and to individual location findings that record the exact file path, line number, and repository where the secret was found. Fencer classifies each secret by type (API Key, Password, Token, Certificate, Private Key, Database Credential, Cloud Credential, Webhook, or Other) and assigns a severity level based on the detection rule that matched.

New secrets also feed the Fail on new secrets exposed check, which is on by default, so a pull request that adds a secret gets a failing check (see Code Scanning — Checks).

Usage / Configuration

Viewing secrets

1. Go to Posture > Secrets. The URL follows the pattern /a/<organization-slug>/secrets/.
2. The list opens filtered to Active secrets, ordered by number of locations and then by detection date. Remove the filter to see secrets in every status.
3. Click any secret in the list to view its details in the right-hand detail panel. Use the arrow keys to move between secrets.

Filtering secrets

Use the filter and search controls at the top of the secrets list to narrow results:

1. Status — Filter by current status (Active, Revoked, Rotated, Expired, False Positive, Will Not Fix, Acceptable Risk, Duplicate, Superseded, Third Party Code, No Fix Available, Rule Disabled).
2. Type — Filter by secret type (API Key, Password, Token, Certificate, Private Key, Database Credential, Cloud Credential, Webhook, Other).
3. Severity — Filter by severity level (Critical, High, Medium, Low, Info).
4. Repository — Filter by the repository where the secret was found.
5. First Detected / Last Detected — Filter by date.
6. Ordering — Sort by title, date, last detected, severity, findings, status, or type.

Reviewing secret details

The detail panel for a selected secret shows:

• Title and severity — The secret’s title, from the detection rule that identified it.
• Locations — How many locations the secret was found in.
• Assets Affected — The number of distinct assets (repositories) affected.
• Status — Current remediation status.
• Assignee and Tracking — Who owns the secret, and any linked Jira or Linear issue.
• View Vulnerability — Opens the underlying vulnerability.
• First Detected and Last Detected — When the secret was first and most recently seen.
• Description and Remediation — Details about the secret and how to fix it.
• Locations table — Every file location where the secret was found, with the asset, severity, status, and when it was first seen, ordered by status and recency.

Updating secret status

Changing a status needs a role that can edit vulnerabilities, such as Administrator or Team Member.

1. In the secret detail panel, click Status.
2. Under Mark as, select a new status:
   • Active — The secret is still exposed and needs attention.
   • Revoked — The credential has been revoked and is no longer valid.
   • Rotated — The credential has been replaced with a new one.
   • Expired — The credential has naturally expired.
   • False Positive — The detection was incorrect.
   • Will Not Fix — Acknowledged but will not be remediated.
   • Acceptable Risk — The exposure is within accepted risk tolerance.
   • Duplicate / Superseded / Third Party Code / No Fix Available / Rule Disabled — Additional ignore reasons.
3. Optionally add Notes explaining your decision, then click Update.

Note

A secret is considered remediated when its status is Revoked, Rotated, or Expired. Only secrets with an Active status require action.

Assigning secrets

1. In the secret detail panel, click the assignee.
2. Select a team member. The selected user will receive a notification.
3. To unassign, open the same picker and clear the selection.

Bulk operations

1. Select multiple secrets using the checkboxes in the list, or select all secrets that match the current filters.
2. Choose a bulk action:
   • Status — Update the status of all selected secrets at once.
   • Assign — Assign all selected secrets to a team member.
   • Linear — Create a Linear issue for the selected secrets (shown when Linear is connected).
   • Jira — Create a Jira issue for the selected secrets (shown when Jira is connected).

Searching secrets via API

You can search secrets programmatically using the search endpoint, authenticated with an API token:

curl "https://app.fencer.dev/api/v1/org/<organization-slug>/secrets/search/?q=<search-term>" \
  -H "Authorization: Bearer <api_token>"

This searches across secret titles and slugs.

Examples

Triaging an exposed API key:

1. Go to Posture > Secrets and filter by Type: API Key and Status: Active.
2. Click on the first result to see where the key was found.
3. Review the locations to identify which repositories and files contain the key.
4. Revoke the API key in the provider’s dashboard (e.g., AWS console, Stripe dashboard).
5. Generate a new key and store it securely (e.g., in a secrets manager).
6. Update the secret status to Rotated and add a note like “Rotated via AWS IAM on 2026-03-04.”
7. Assign a team member to remove the hardcoded value from the codebase.

Troubleshooting

• No secrets shown but scans have completed — Secret detection runs only when your plan includes secret scanning. Also check that the list isn’t filtered to a status (it shows only Active secrets by default), and that the files aren’t skipped by the repository’s Exclude files or directories setting or an inline nofencer comment.
• Secret appears as “Other” type — This means the detection rule did not map to a specific secret type. The secret is still valid and should be reviewed based on the rule name and description.
• Same secret appears multiple times — Secrets are deduplicated by their hashed value. If you see what looks like duplicates, the detected values are actually different (e.g., different API keys for the same service).

Caution

Always revoke or rotate exposed secrets immediately, even if you believe the repository is private. Secrets committed to version control persist in Git history and may be accessible through forks, backups, or future access changes.

Related pages

• Code Scanning
• Dependency Scanning
• Vulnerability Management