feat(detectors): add Rancher/Cattle token detector

[toor11]

Summary

Closes #4622. Adds a detector for Rancher API tokens (used by the Rancher Kubernetes management platform, deployed at 37,000+ organizations).

Detection Strategy

Tokens are anchored to known Rancher/Cattle variable names to avoid false positives on generic [a-z0-9]{54,64} strings (as flagged in the issue):

CATTLE_TOKEN, RANCHER_TOKEN, CATTLE_BOOTSTRAP_PASSWORD, RANCHER_API_TOKEN, RANCHER_SECRET_KEY

Regex pattern:

(?i)(?:CATTLE_TOKEN|RANCHER_TOKEN|CATTLE_BOOTSTRAP_PASSWORD|RANCHER_API_TOKEN|RANCHER_SECRET_KEY)[\w]*\s*[=:]\s*["']?([a-z0-9]{54,64})["']?

Verification

Verification requires a live Rancher server URL (CATTLE_SERVER) which is not available at scan time. Matched tokens are returned as unverified. A future enhancement could extract CATTLE_SERVER from the same context chunk and attempt GET {server}/v3 with Authorization: Bearer {token}.

Changes

• pkg/detectors/rancher/rancher.go — detector implementation
• pkg/detectors/rancher/rancher_test.go — pattern tests (env file, quoted values, no-context rejection, length rejection)
• proto/detector_type.proto — Rancher = 1050
• pkg/pb/detector_typepb/detector_type.pb.go — generated enum update
• pkg/engine/defaults/defaults.go — registered &rancher.Scanner{}

Test Results

ok  github.com/trufflesecurity/trufflehog/v3/pkg/detectors/rancher  0.391s

---

Note

Low Risk
Additive detector-only change with no auth or scan-engine behavior changes; main review focus is regex false positives/negatives and unverified findings.

Overview
Adds Rancher/Cattle API token detection for secrets commonly set as CATTLE_TOKEN, RANCHER_TOKEN, CATTLE_BOOTSTRAP_PASSWORD, RANCHER_API_TOKEN, or RANCHER_SECRET_KEY, paired with a lowercase alphanumeric value 54–64 characters (quoted values and = / : separators supported). Matches are deduplicated and emitted as unverified results—there is no live verification against a Rancher CATTLE_SERVER URL.

Registers the new rancher.Scanner in the default detector list and extends DetectorType_Rancher = 1058 in proto/detector_type.proto and generated protobuf code. rancher_test.go covers env-style assignments, quoted secrets, and negative cases (wrong variable name, bad length, uppercase token, overlong suffix).

^{Reviewed by Cursor Bugbot for commit 43a667b. Bugbot is set up for automated code reviews on this repo. Configure here.}

[CLAassistant]

All committers have signed the CLA.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

There are 2 total unresolved issues (including 1 from previous review).

^{Reviewed by Cursor Bugbot for commit 5c0ee37. Configure here.}

[gugacyber]

Nice work on this detector, the regex scoping of (?i:PREFIX) and the \b boundary fix are exactly right.
One thing worth checking: DetectorType_Rancher = 1050 may conflict with DetectorType_GitLabOauth2 = 1050 which was registered in a recent merge (#4950s range). Worth verifying the enum value against current main.
Also noticed the Scanner struct doesn't implement Description() string, other detectors in the codebase include it (e.g. stripe.go line 83). Not a blocker but keeps things consistent.
Overall the detection logic looks solid. The anchored variable name approach is the right call for a generic-looking token format like this.

[toor11]

Thanks for the careful review, @gugacyber! 🙏 Both of your points are handled:

• Enum value: Rancher is currently 1053 in detector_type.proto, and I verified there are no duplicate enum values — the generated detector_type.pb.go matches at DetectorType_Rancher = 1053, so there is no collision with GitLabOauth2 = 1050.
• Description(): implemented on the Scanner struct (pkg/detectors/rancher/rancher.go L58–61), consistent with the other detectors.

The Cursor Bugbot items (scoped (?i:...), the \b boundary, and alphabetical ordering in defaults.go) were addressed in the earlier commits. I think it is ready for another look whenever a maintainer has a moment — thanks again for the thoughtful feedback!

[toor11]

@MuneebUllahKhan222 — apologies for the direct ping, and please redirect me if this isn't yours. This PR (adds the Rancher/Cattle token detector requested in #4622) has been open since May 12 without a reviewer assigned, and I believe it's ready.

Status

• CLA signed.
• All four Cursor Bugbot findings addressed: (?i:...) scoped to the variable-name prefix only (token capture stays case-sensitive), \b boundary so a longer string can't match on a truncated 64-char prefix, results returned as unverified (Verified=false, no VerificationError) since there's no live verification path, and import + scanner registration placed alphabetically between ramp and rapidapi.
• Review feedback from @gugacyber addressed.
• As of my last rebase (Jul 6), go test ./pkg/detectors/rancher/ and go test ./pkg/engine/defaults/ both passed.

On the conflict

The only thing marking this conflicting is the DetectorType enum value. Since the numbers are handed out next-sequentially, every open detector PR contests the same one, so an unmerged PR can't hold a number: Rancher has already been renumbered twice (1050 → 1053 → 1058), each time displaced by a detector that merged first — most recently NewRelicInsightsInsertKey took 1058 in #4778. It would be 1062 today, and it will drift again the next time a detector lands.

Rather than keep rebasing into a value that's contested by construction, I'd rather do it once, when it actually counts: whenever you're ready to look at this — or just start a review — I'll renumber to the next free value and push straight away so it lands clean.

Happy to make any other changes you'd like.