A verified-only report leaves unresolved credentials out
TruffleHog can check candidate credentials against provider APIs. A report limited to verified results therefore answers a narrower question than whether a repository contains potential secrets: it shows credentials confirmed as active by those checks.
The README distinguishes three statuses. Verified means API testing confirmed a credential as valid and active. Unverified means a candidate was detected but not confirmed valid, which can include disabled verification. Unknown means verification was attempted but encountered an error, such as a network or API failure. Neither an unknown result nor an unverified result establishes that a candidate is harmless.
That distinction matters when choosing a blocking check. Decide who investigates unresolved candidates, when verification should be retried and how scan errors affect the job. A quiet filtered report alone does not establish that every candidate was resolved or that the intended content was scanned.
What happened when we ran it
Our recorded run at commit 0e42739 on 2026-10-09 recorded an install step that exited 0 after 72 seconds, with 596 dependencies recorded. The recorded build step exited 0 after 316 seconds. These successful step statuses do not independently demonstrate a compiled binary or installed CLI: the prior-page evidence identifies a Go download in the install tail and only vet-exit:0 in the build tail. No installed-binary execution was demonstrated.
The test command exited 1 after 555 seconds. The parser reported 994 successful package results and 58 failing package results, totaling 1,052. These figures are package-result counts, not counts of individual passing and failing tests. Exhaustive unique counts were not reconciled against the complete logs, so they should not be used as a test pass rate.
The supplied tail marks the S3 and Travis CI source packages as failed and includes a failing TestSource_Scan. It does not show the assertions or errors behind those failures. Missing credentials, network restrictions and integration defects remain possible explanations to investigate, not findings established by this tail. The failed command also does not establish that every scanning mode is broken.
The configured sandbox had 3 CPUs, 8 GB RAM and image golang:1.24-bookworm. That label does not establish the executing Go or operating-system version. The checkout contained 3,541 files, approximately 483,563 source lines and 22.3 MB of files, with ten CI workflow files and a Dockerfile. The recorded absence of a standalone tests directory does not mean a Go repository lacks tests.
No measured secret-detection workload accompanies these repository checks. We cannot infer missed-secret rates, false-positive rates or scan throughput from command statuses or package results. The next useful evaluation is a source-specific trial with known expected findings and an explicit check that the intended content was processed.
Set verification and error policies separately
The README documents provider verification and the option to disable it with --no-verification. A local filesystem source does not make active verification an offline operation. If provider requests are prohibited, disable verification and review other network behavior before describing the deployment as fully offline.
Source access is a separate decision. A local directory, a private repository and a cloud bucket require different permissions. Limit access to the authorized source and restrict who can read the results. The README's JSON example includes a raw credential value, so output storage and build logs belong in the secret-handling plan.
The documented CLI exposes both result filtering and scan-error handling. Its help describes --fail as exiting with code 183 when results are found, while --fail-on-scan-errors requests a nonzero exit when a scan error occurs. Treat these as separate controls: finding policy does not replace checking whether the scan completed without errors. These are documentation-based descriptions; we did not execute those options.
For an initial trial, record the scanner version, source scope, selected result classes and permitted provider requests. Check expected findings as well as scan errors, then assign an owner for each unresolved result before expanding coverage.
Keep the measured checkout separate from release evidence
The supplied release evidence identifies v3.99.7, published on October 24, 2026. Its release notes list an Anypoint OAuth2 detector fix to stop treating HTTP 422 as verified. That is a specific detector change, not evidence that every detector previously treated that response the same way.
The release postdates our October 9 run at commit 0e42739. Our recorded command results therefore do not validate v3.99.7. The supplied README is also not presented as a snapshot pinned to the measured commit. Use it to identify workflows to qualify, then check the behavior of the exact scanner version you plan to deploy.
Compare baseline workflows when preventing new findings
Gitleaks documents configurable rules and a baseline that excludes previously recorded findings. It is worth evaluating when the immediate task is controlling new findings in a repository. Its README also says future releases will be security patches only, which belongs in the maintenance decision. We have no comparative speed or detection-accuracy measurements.
Yelp's detect-secrets documents separate commands for creating a baseline, checking new findings and auditing recorded candidates. Its staged-file example suits a team introducing checks while organizing existing findings for cleanup. The documentation includes optional network verification and a switch to disable it; baseline support does not itself imply offline operation.
Choose between these workflows by the work your team needs to do. For TruffleHog, provider verification is a reason to evaluate it when active credential status helps prioritize a response. Before making that evaluation a blocking job, demonstrate that the selected version reads the intended source and handles unresolved candidates and scan errors according to your policy.
Why the ratings are unassessed
The score fields remain N/A because the evidence does not support numerical product ratings. Recorded command statuses cannot establish setup ease without a demonstrated installed CLI. Documentation coverage does not establish that every instruction works, and repository activity does not measure support quality. The failed test command needs investigation, while detection accuracy and production reliability require workloads absent from this packet.