Terminology

release stages private preview private preview features are early stage capabilities made available to a limited group of design partner customers ahead of general release these features are functional but may have known limitations, evolving interfaces, or reduced support coverage compared to fully released features customers participating in private preview provide feedback, may encounter occasional rough edges, and work directly with truffle to validate the feature in real world conditions documentation and support resources may be limited during this stage general availability (ga) a feature reaches general availability once it has met truffle's enterprise quality bar for functionality, stability, performance, security, and supportability ga features are available to all customers, fully documented, covered by standard support, and included in published release notes ga features are enabled on truffle's regular monthly release day, giving customers predictable timing and advance notice to support change control requirements configuration sources integrations that provide data to be scanned they are configured via a local configuration file, or in the web ui examples of sources include slack, jira, github, s3, etc see the scan for secrets docid 91jgobvg nkxphml0ko7k part of the documentation for more information notifiers integrations for sending notifications for found secrets examples of notifiers include email, slack message, jira ticket, or a webhook see the notify results docid 3x2gi1gjncqbcagjfqssw part of the documentation for more information scanners (agents) the component that scan for secrets and verify them metadata of the secret is sent to the configured notifiers and to your hosted web ui see the rest of the getting started docid\ thkh glbmurkdwud7wbmh documentation for creating and configuring a scanner scanner group (agent group) used to manage multiple scanners you configure scanner groups in the web ui a scanner group can run more than one scanner instance, and scan jobs will run across those instances detectors the individual rules and signature types that trufflehog uses to find secrets, credentials, and other sensitive data across source code, logs, configs, containers, cloud resources, and more each detector focuses on a particular kind of secret to customize detection see the custom detector https //docs trufflesecurity com/custom detectors documentation scanners hosted scanner a scanner that runs in truffle security's infrastructure, in an isolated environment dedicated to your tenant truffle security manages the compute, updates, and availability with no setup or maintenance on your end every tenant has a default hosted scanner group best for getting started quickly self hosted scanner a scanner that runs on hardware you operate (kubernetes, vm, or container host in your own network) you manage the compute self hosted scanners live in their own scanner group , created in the web ui best for sources that aren't reachable from the public internet, or when data residency or network isolation requires scanning inside your environment secrets secrets, or more generally credentials, are the data that is scanned for examples of secrets include access keys/tokens, api keys, passwords, etc secret states live the secret is verified and is active not live this secret was tested and was never verified as active rotated/deactivated the secret was verified as live at one point, and has since been verified as not live all any secret that was found triage states triage states can be used to label where a finding sits in your review process common usage open states findings still requiring action or investigation not triaged the finding is new and has not been reviewed no determination has been made about validity, risk, or ownership in review a finding being investigated to determine validity, ownership, scope of exposure, or appropriate response notified the responsible party (secret owner or owning team) has been informed of the finding awaiting acknowledgement or action in progress remediation work has begun, such as rotating, revoking, or removing the secret from the exposed location closed states findings that no longer require active work resolved the secret has been remediated by being rotated, revoked, removed, or verified as no longer active invalid a false positive the detected value is not a functional secret or was incorrectly identified by the detector exception the secret represents a known, accepted risk, often after a security review determined the exposure is tolerable given compensating controls, limited scope of impact, or business justification we recommend tracking an owner and review date alongside exceptions will not fix the finding is intentionally and permanently dismissed with no expectation of future review, such as canary tokens, honeypots, or other intentional placements