feat: add Rancher/Cattle token detector

[moeedrehman135]

Summary

Adds a detector for Rancher/Cattle API tokens as requested in #4622.

Changes

• New detector in pkg/detectors/rancher/
• Regex matches CATTLE_TOKEN, RANCHER_TOKEN, CATTLE_BOOTSTRAP_PASSWORD, RANCHER_API_TOKEN patterns
• Requires server context (CATTLE_SERVER or RANCHER_URL) nearby to reduce false positives
• HTTP verification against Rancher v3 API
• Pattern tests included
• Registered in defaults.go

Testing

All pattern tests pass:

• Valid token with server context
• Invalid token (too short)
• Token without server context (should not detect)

Closes #4622

---

Note

Medium Risk
Adds a new secret detector with optional live HTTP verification and wires it into the default detector set; main risk is false positives/negatives or unintended network calls when verify is enabled.

Overview
Adds a new rancher detector that identifies Rancher/Cattle API tokens only when a matching CATTLE_SERVER/RANCHER_URL is present, and (optionally) verifies candidates via a GET /v3 request using a Bearer token.

Registers the new detector in the default detector list and introduces a new DetectorType_Rancher enum value in protobuf-generated types, with accompanying pattern tests and a benchmark.

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

[CLAassistant]

All committers have signed the CLA.

[cursor]

Token regex won't match real Rancher token format

High Severity

Real Rancher API tokens use the format token-xxxxx:yyyyyyyyyy (containing hyphens and colons), as documented in Rancher's official API docs. The capture group [a-z0-9]{54,64} only allows lowercase alphanumerics, so it will never match actual CATTLE_TOKEN or RANCHER_TOKEN values. The test data uses a fabricated token (kubeadmin5f8a3b...) that doesn't resemble any real Rancher token format, masking this fundamental mismatch.

 

^{Reviewed by Cursor Bugbot for commit 86cc6fa. Configure here.}

[cursor]

Missing multi-part credential provider causes missed detections

Medium Severity

The Scanner struct doesn't embed detectors.DefaultMultiPartCredentialProvider, even though the detector requires two distinct patterns (server context via serverPattern and secret via tokenPattern) to co-occur in the same data chunk. Without this, the Aho-Corasick span calculator uses its default 512-byte radius, so if the server URL and token are farther apart in the scanned data, the chunk delivered to FromData may lack one of the two patterns, causing valid credentials to be silently missed. All comparable multi-part detectors (e.g., mattermostpersonaltoken, formsite) embed this provider.

 

^{Reviewed by Cursor Bugbot for commit 74f5a74. Configure here.}

[cursor]

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

There are 3 total unresolved issues (including 2 from previous reviews).

^{Reviewed by Cursor Bugbot for commit 7401a70. Configure here.}

[cursor]

Deferred body close accumulates in loop iterations

Medium Severity

The defer res.Body.Close() is inside a for loop, so response bodies won't be closed until FromData returns rather than at the end of each iteration. This accumulates open connections/file descriptors across iterations. A comparable detector (pivotaltracker) with nearly identical structure correctly uses res.Body.Close() without defer in its loop.

 

^{Reviewed by Cursor Bugbot for commit 7401a70. Configure here.}