Exported Secrets Column Definitions

In the TruffleHog dashboard your secret findings can be exported as a CSV file.

commit — A unique fingerprint for a specific save point in a Git repository. Every time code is committed, Git generates this ID. It tells you exactly which version of the code contained the secret.

file_name — The name of the file where the secret was found. (e.g. a config.py or .env).

found_on — The date and time the secret was first discovered by a scan.

last_seen — The most recent date and time the secret was observed. If this keeps updating, the secret is still present.

repository — The codebase or project being scanned. Think of it as the folder/project that contains all the source code.

source — Name of the trufflehog source integration in which the secret location was found.

vcs_type — Stands for Version Control System. This tells you what tool manages the code history — almost always git Only used by CircleCI integrations. What VCS platform CCI integrates with like Github or Bitbucket. 

build_number — A sequential number assigned to each run of an automated build or deployment pipeline. Helps you find the exact run where the secret appeared.

build_step — The specific phase of a pipeline where the secret was found (e.g. "test", "deploy", "docker build").

pipeline — The name of the automated workflow that was running. Only populated by Buildkite integrations

bucket — A cloud storage container (like an Amazon S3 bucket or Google Cloud Storage bucket) where files are stored. TruffleHog can scan these for secrets.

image_hash — The unique fingerprint of an entire container image. Also called a digest. Uniquely identifies one exact version of an image.

layer_hash — Container images are built in layers, like a stack of changes. This is the unique ID of the specific layer that contained the secret.

region — The geographic cloud region associated with the resource (e.g. us-east-1 (AWS Virginia) or eu-west-1 (AWS Ireland). Note: Only populated for AWS ECR. 

registry — The service that stores and distributes container images. (e.g. Only in Amazon ECR. 

tag — A human-readable label attached to an image version, like latest, v2.1.0, or production.

channel_identifier — The internal unique ID of that channel, used by the platform to distinguish it from others with similar names.

channel_name — The name of a messaging channel where the secret was posted — for example, a Slack channel called #deployments.

page — A specific page in a documentation or wiki tool (like Confluence or Notion) where the secret was found.

snippet_id — The ID of a specific code snippet or message excerpt where the secret appeared. Only for Bitbucket and Sharepoint integrations. 

space — A top-level section or grouping within a wiki platform. Pages live inside spaces.

timestamp — The exact date and time a message or event containing the secret occurred.

version — The version number of the package or software release where the secret was detected. Confluence only field. 

workspace_id — The unique ID of a team workspace. Used to identify which workspace the finding came from. Only available for Postman. 

workspace_name — The human-readable name of that workspace, like "Acme Corp". Only for Bitbucket and Postman integrations

package_name — The name of a software package that was scanned — for example, an npm package or a Python library.

release_name — The name of a specific release of that package, such as v3.0.0 or stable.

account_name — The name of a cloud or service account linked to the secret — for example, an AWS IAM user name.

email — The email address of the user associated with the finding.

org — The organization that owns the repository or resource — for example, a GitHub organization like acme-corp.

user_id — The unique internal ID assigned to a user by a platform (only used by Slack and Microsoft Team). Jira is the author. 

username — The display name or handle of the person associated with the secret. For example, the Git committer or the person who posted a message.

decoder_type — How the secret was encoded in the source. TruffleHog tries multiple decoders to catch secrets that are obscured. Examples: plain (raw text), base64 (encoded string), utf8.

redacted — A masked version of the secret, where most characters are replaced (e.g. AKIA************). Safe to display without exposing the real value.

secret_type — What kind of secret was found. Examples: AWS Access Key, GitHub Personal Access Token, Stripe Secret Key, Google API Key.

triage_state — The current status of the finding in your review workflow. Common states: unresolved (needs action), resolved (fixed), ignored (intentionally dismissed).

verified — Whether TruffleHog confirmed the secret actually works based on last_seen date. A verified secret means it was tested against the real service and is live and valid — these are the highest priority to fix.

verification_error_type — If TruffleHog tried to verify the secret but something went wrong, this is the broad category of what failed. Example: timeout, network_error.

verification_error_subtype — A more specific explanation of the verification failure. For example, if the error type is network_error, the subtype might tell you it was a DNS resolution failure or an SSL certificate issue.

id — A unique identifier for this specific finding (not the location) within TruffleHog. Used to reference or look up the finding programmatically.

issue — A linked ticket in a project management or issue tracking tool (like Jira or Sentry Issues) associated with this finding.

link — A direct URL to the secret for the source where it was found.

title — A short, human-readable summary of the finding.

TruffleHog link — A direct URL into the TruffleHog platform for this specific finding. Useful for sharing findings with teammates or linking from other tools.