Exported Secrets Column Definitions

in the trufflehog dashboard your secret findings can be exported as a csv file core identity & source 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 ci/cd 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 container & registry 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 communication & collaboration 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 & release 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 user & account 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 secret classification 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 errors 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 other 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 questions is there a unique identifier for each secret that we can use to correlate findings? answer yes, each finding has a stable identifier the secret id (a numeric value) the csv is structured as one row per location , not per secret if the secret 1234 appears in 5 places, you'll get 5 rows sharing the same secret id this is why the export row count can be much higher than the dashboard's secret count to match the dashboard numbers, deduplicate the export on the secret id, or use the api (list secrets + countitems)