Betterleaks v2 makes provider-request modes explicit, but migration also requires checking which configuration loads and whether your pipeline can read the reports. Our source checks passed at v2.0.0-rc.6. They do not establish that an existing scanning integration will work unchanged.
For security and CI engineers, the useful evaluation is a controlled migration trial: select the intended rules, choose whether providers may be contacted, and check that findings reach their destination.
Choose the provider-request mode
The measured-commit README says scans detect secrets without credential-provider requests by default. Validation checks supported credentials; analysis also resolves identity and permissions where supported. Analysis implies validation.
Optional validation is not new to v2. The migration guide says v1 also required an opt-in flag to contact providers. In v2, -v means validation rather than verbose output. Review scripts that carry that flag forward.
BETTERLEAKS_VALIDATE and BETTERLEAKS_ANALYZE can enable provider work through the environment. Explicit flags override the corresponding variable. Set the intended mode in the CI job so inherited settings do not decide it accidentally.
Detection-only does not make remote source retrieval offline. Use a local source when you need to separate retrieval from detection. Our sandbox record contains no provider-request trace or remote scanning workload.
Revocation requires a separate explicit command and rule support. Scans never revoke credentials. A finding still needs an incident-response decision about revocation and replacement.
Check configuration selection and report ingestion
V2 no longer automatically discovers target-local .betterleaks.toml files. The migration guide documents explicit selection through a flag or environment setting, followed by embedded defaults. An existing command can therefore run with different rules than its owner expects.
The guide also documents a new JSON envelope and finding schema, plus a final scan summary in JSONL. Check dashboards, ticket importers and other report consumers before changing versions. A successful scan is insufficient if the next step drops its findings.
Betterleaks recommends maintaining your own production configuration instead of directly extending upstream defaults. This lets you review upstream rule changes before adopting them, but it also requires someone to maintain the deployed rules.
Contextual filters can inspect paths, Git attributes and candidate finding data. These controls can exclude irrelevant matches. Our run measured no false-positive reduction. Review exclusions against representative material because broad filters can also suppress findings you wanted to retain.
What happened when we ran it
Our October 31, 2026 sandbox run at ededafe installed successfully in 58 seconds, built in 57 seconds and passed all 47 recorded go test entries in 38 seconds. All recorded steps succeeded. These are source-check results, not a scanner-effectiveness benchmark.
The installation record lists 162 dependencies. The checkout contained 845 files, approximately 96,225 source lines and 5.2 MB of checked-out material. That size is not the installed footprint of the scanner and its dependencies.
The recorded sandbox configuration was 3 CPUs, 8 GB RAM and image golang:1.24-bookworm. The image label does not establish the executed Go or operating-system version. Repository signals recorded 2 CI workflow files, a Dockerfile and no tests directory. The absence of that directory is not a test-coverage assessment.
The record does not measure detection accuracy, false positives, provider validation or scanning speed on a representative workload. It includes no comparative scanner workload or vulnerability audit result. Evaluate those questions separately before replacing a working scanner.
Pin the release candidate
The release page identifies ededafe as v2.0.0-rc.6, a prerelease. The README assigns main to v2 development and v1.x to v1 maintenance. It warns that package managers and Docker latest may still supply v1 before stable v2.
Pin the version you intend to evaluate and confirm its interface. Do not attach the source-check timings here to a package-manager or container installation without a matching run.
Supplied repository metadata, observed on November 2, 2026, records the last push as October 31, 2026 at 14:57:42 UTC. Dated issue-response evidence was not supplied. A recorded push and release candidates do not establish support capacity or production reliability; those remain unassessed.
Decide whether migration solves a problem
Gitleaks detects secrets in Git repositories, files and stdin. Its README says it is feature complete and future releases will be security patches only. Keeping an existing Gitleaks integration is reasonable when it meets your detection needs and the Betterleaks migration offers no required capability.
TruffleHog documents credential discovery, validation and analysis. Evaluate it alongside Betterleaks when provider-backed checks are central to your workflow. The supplied measurements establish no detection-quality advantage for either tool.
For a trial, retain your current scanner's report and run a pinned Betterleaks version on the same authorized sample. Compare findings and exclusions manually, then check that your report consumer preserves the findings you need to act on.